「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の教祖様

Re:門外漢ですが

[L.star (163)]

今のPostgreSQLのボトルネックは、8.1以降大きく解消したとはいえ各種内部ロックなので、mmap()にしてもそんなに快適にはならないような気がする。

それに、キャッシュのヒット率を上げるなら、メモリの有効活用よりバッファアルゴリズムを改良するとか他にやることがある。まあ、mmap()辺りの話は昔からずっと言われている割には全然実現していないので、移植性の問題か、はたまたみんなやる気がないのかな、とか思っている。

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の教祖様

Re:門外漢ですが

[Anonymous Coward]

そこで、GNU Hurdですよ