[pgsql-jp: 37628] Re: VACUUM FULL の物理的なテーブルの切り詰め方について

miyamoto @ intellilink.co.jp miyamoto @ intellilink.co.jp
2006年 11月 1日 (水) 09:55:33 JST


宮本です。

岡野さん。返答ありがとうございます。

確かに、repair_frag関数のコメントに、
ブロック番号の大きなほうから0ブロック目に近いほうにレコードを移動させる
ように記述されていました。

不要領域より後ろの領域を全て移動させたら、書き込みが多くなってしまうので
このようにしているのかも知れませんね。

ご教授、ありがとうございました。

Quoting Katsuhiko Okano <okano.katsuhiko @ oss.ntt.co.jp>:

> 岡野と申します。
>
>> VACUUM
>> FULLを実行すると、物理的に不要領域が削除されてテーブルサイズが小さくなりますが、
>> 不要領域が削除された分、不要領域より後ろの使用済み領域が、順々に前へ押し出されていくのでしょうか?
>> (不要領域より後ろの領域が全て移動するのでしょうか)
>> それとも、削除される不要領域のサイズに合わせて、適した使用済み領域を当てはめていき、テーブルサイズを小さくしているのでしょうか?
>> (不要領域より後ろの領域の一部のみが移動するのでしょうか)
>> それとも、全く別の方式でしょうか?
>
> src/backend/commands/vacuum.c の中のrepair_frag関数に、コメントで
> 以下の記述があります。
> /*
>
> * Scan pages backwards from the last nonempty page, trying to move tuples
>
> * down to lower pages.  Quit when we reach a page that we have moved any
>
> * tuples onto, or the first page if we haven't moved anything, or when we
>
> * find a page we cannot completely empty (this last condition is handled
>
> * by "break" statements within the loop).
>
> *
>
> * NB: this code depends on the vacuum_pages and fraged_pages lists being
>
> * in order by blkno.
>
> */
>
>
> これらを見ると、順々に前へ押し出すのではなく、
> ブロック番号の大きなほうから0ブロック目に近いほうにレコードを移動させる
> (そのためレコードの順番が変わる)のではないでしょうか。
> --------
> Katsuhiko Okano
> okano katsuhiko _at_ oss ntt co jp
>





pgsql-jp メーリングリストの案内