ザク豆腐

blog20120712-ZakuTofu

ザクの形を模した木綿枝豆豆腐。右に写っているのが容器。角の形の爪楊枝と付けろとか、赤はないのかとか、お味はもう少し枝豆風味を強くしても良かったかなとか、味で判断するなら男前豆腐店の方が好みだなとか。

— posted by mu at 09:48 pm   commentComment [0]  pingTrackBack [0]

PostgreSQLで遅くなるクエリ

CentOS 4.9Link &PostgreSQLLink (postgresql-server-8.1.11-1.el4s1.1)での話。

  • 200以上のカラムを持つテーブルが数10あるDBを構築
  • 各テーブルにはName varchar(10)とTime datatimeのカラムを含む
  • Nameに対してbtreeのインデックスが張ってある
  • 同じNameを持つ行が1~数行存在し、 NameとTimeの組み合わせでは重複は無い

こういうテーブルに対し以下のSQLを発行すると2~3秒かかる現象が。

SELECT max(Time),min(Time) FROM table1 WHERE Name='hoge'

つまりName='hoge'がどの時間範囲で存在しているかを知るのが目的。似たような構造を持つテーブルは他にもたくさんあるのに、現象が発生するテーブルは一つだけ。しかもデータ行が100万を越えた辺りから発生する。テーブルを一旦削除してデータを入れなおしても同じ。

一方以下のクエリは見た目一瞬で完了。

SELECT Name FROM table1 WHERE Name='hoge'
SELECT count(Name) FROM table1 WHERE Name='hoge'

最終的に以下のクエリが期待している速度で完了するようなので、理由はともかく採用。

SELECT max(Time),min(Time) FROM table1 WHERE Name='hoge' GROUP BY Name

Name自体はSELECTする項目ではなくWHERE句でもNameは単一として指定しているので、GROUP BYの有無に関わらず出る結果は同じはず。一方オプティマイザは両者では異なる方針を出すようで、GROUP BYを付けないとインデックスを2回使ったりTimeがNULLかどうかを調べたり。

db1=> explain SELECT max(Time),min(Time) FROM table1 WHERE Name='hoge' GROUP BY Name;
                                          QUERY PLAN                                          
----------------------------------------------------------------------------------------------
 GroupAggregate  (cost=0.00..2908.69 rows=1 width=22)
   ->  Index Scan using index1 on table1  (cost=0.00..2901.15 rows=1003 width=22)
         Index Cond: (Name = 'hoge'::bpchar)
(3 rows)

db1=> explain SELECT max(Time),min(Time) FROM table1 WHERE Name='hoge';
                                                   QUERY PLAN                                                   
----------------------------------------------------------------------------------------------------------------
 Result  (cost=526.88..526.89 rows=1 width=0)
   InitPlan
     ->  Limit  (cost=0.00..263.44 rows=1 width=8)
           ->  Index Scan Backward index1 on table1  (cost=0.00..264491.27 rows=1004 width=8)
                 Filter: ((Time IS NOT NULL) AND (Name = 'hoge'::bpchar))
     ->  Limit  (cost=0.00..263.44 rows=1 width=8)
           ->  Index Scan using index1 on table1  (cost=0.00..264491.27 rows=1004 width=8)
                 Filter: ((Time IS NOT NULL) AND (Name = 'hoge'::bpchar))
(8 rows)

う~む、よく分からん(- -;)

— posted by mu at 12:19 pm   commentComment [0]  pingTrackBack [0]

G-Tune NEXTGEAR Note i300到着

blog20120623-GTune_i300

もちろんPSO2Link を実家・出張先でやるため。坊や、運が悪かったね、こんな家に来たばっかりに遠い国(注:フィリピン)に連れて行かれてしまうんだよ…

早くから候補は軽さのG-Tune NEXTGEAR Note i300Link かコストパフォーマンスのHP Pavilion dv6-7000Link に絞ってたのですが、そこから結構悩んだ末軽さを選ぶことに。(さすがに金に糸目をつけずRetinaディスプレイMac book ProLink に行こうとは思わなかった^_^;)

ACアダプタがでかいと言われていたのですが、先代 Vostro 1500Link のそれより少し小さいくらい。もっと大きいのかと思ってたので拍子抜け。Vostro 1500と同じ90W出力なんだからこれくらいしょうがないと思う。

もうひとつの気がかりだった光沢液晶は反射低減フィルムLink を貼ってみたのですが、効果はあるものの本物のノングレアのようにはならず(まぁ技術的に難しいとは思うけど)

しかしノートPCにデスクトップPC用のマニュアル付けてくるのはさすがマウスコンピュータLink 。Acerの紙ぺら1枚よりマシだし私は読まないから、その分コストダウンにまわしてくれればいい。

同時にメモリとSSDも購入し換装する気満々。写真は一回もOS起動されることなく換装されるHDDをバックアップしている最中のもの。


— posted by mu at 04:46 pm   commentComment [3]  pingTrackBack [0]

PSO2 Open β開始

blog20120622-PSO2NewAccountRejected

○| ̄|_

残業から帰って入ってみればこの仕打ちw

— posted by mu at 12:52 am   commentComment [0]  pingTrackBack [0]

私も最初理解できなかったような

このブログに何度か登場しているアメリカ人Link 、現在日本に来ておりまして私と一緒に仕事をしております。日本語が少々通じますので一人でもいろんな所に行っちゃいます。

で、"昨日"(台風真っ只中だったのですが、本当に昨日だろうか?)、チーズケーキを買いに行って「お時間は?」と(もちろん日本語で)聞かれて混乱したらしい。保冷剤を入れるかどうかを判断するため帰宅までの時間を聞かれていたわけですが、アメリカではそんな商習慣はないらしく、今は注文だけで受け取りは後なのかと悩んだとか。

言われてみれば確かに混乱すると思う。まぁ似たようなことは私がアメリカに行けば日常茶飯事で経験(*1)したわけですが、立場が逆になると気づかないもんだ。

というわけで、ケーキ店等にお勤めの方、外国人と応対するときはお気をつけくださいませぇ~(笑)

(*1) KFCで(セットのクッキーにつける)蜂蜜かバターを選べと聞かれているのがまったく理解できなかったとか orz

— posted by mu at 10:55 pm   commentComment [0]  pingTrackBack [0]

T: Y: ALL: Online:
ThemeSwitch
  • Basic
Created in 0.0165 sec.
prev
2024.11
next
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30