「PostgreSQLのINSERT/UPDATEを数十倍高速化するSigres」記事へのコメント

門外漢ですが

[Anonymous Coward]

あのぅ、これ以上メモリ食わないでくださぃ

Re:門外漢ですが

[okky (2487)]

私も門外漢ですが。

今の DBMS は read/write でデータを読み書きしている。write はともかく、read の方は、
read only な mmap にしてくれないかな。変更するときにコピーをとって write するって事で。

というのは、read/write は kernel 側と DBMS 側に1つづつページのコピーを持っている。
kernel 側は「手元にあるこのキャッシュのコピーは、DBMS 側がもっているあのページと
同じものだ」という事が判らないので(read とは「コピーしてよこせ」という意味ですので)
これじゃ、4Gあったとして、全部データに使えても実質2Gbyteしか使えない事になる。
mmapなら kernel cache と DBMS 側のページが「同じもの」と判るので、少しだけでも
この無駄が減る。

高速化の前にこの辺の無駄を削ってからの方が、トータルスループットが快適に上がると思うだが…。

--
fjの教祖様

64bits向けなら好し(?)

[Anonymous Coward]

( mmap() + munmap() ) × n は
fopen() + ( fseek() + fread() ) × n + fclose() より大抵遅いので、
一般的な32bits環境では mmap() しっぱなしでどうにかなる
全体が4GB未満のデータベースでしか速くならない
ってことになるんじゃないですかね。

Re:64bits向けなら好し(?)

[okky (2487)]

うーん。 mmapを使う事でコピーを減らしてメモリの利用効率が上がると、n の数自体が減ると思いますが。 # 十分多きな DB に対しては変わらんか。 あと、前から思っているんだけれど… > ( mmap() + munmap() ) × n は > fopen() + ( fseek() + fread() ) × n + fclose() より大抵遅いので、 これ本当かなぁ?? いや、advice なしで mmap/munmap 使ったら、sequential read では、遅いのは全くもってその通りと思うけど…。 # 文字通りの on demand になるので、4kbyte づつ粉々に、ランダムに読み込むのに等しい。 # それなら、fread() がキャッシュを使って、一気に数Mbyte読むように仕向ければ、 # 圧勝だろう、と私も思う。 『HDDとのIOが支配的』な世界では、madvise で MADV_SEQUENTIAL と MADV_WILLNEED 与えれば、実質 fread() と同じ HDD IO 挙動をしてくれるはず。順番にアクセスするぞ、必要になるぞ、さぁ先読みしろ、と教えるわけですから。『大抵遅い』になるとは到底思えない。 # 時間が出来たら実験しよう…。

--
fjの教祖様