[pgsql-jp: 42062] Re: BRIN indexについて

NISHIMURA Yutaka iscream @ nugae.org
2020年 9月 18日 (金) 09:47:30 UTC


西村です。

> 2020年9月18日(金) 17:29 NISHIMURA Yutaka <iscream @ nugae.org>:
> >
> > 西村です。
> >
> > > 海外です
> > >
> > > 横から失礼します(シュッ!
> > >
> > > CLUSTERコマンドは内部的に CREATE TABLE AS SELECT .... ORDER BY index_key と
> > > 同じ事をやっています。テーブルに紐づいたファイルの物理的にもう一つ作成し、それを
> > > スワップする事で、「物理的に望ましい順序」でデータが配置されたテーブルを作っています。
> > > ですので、わざわざ b-tree を一度作成するくらいなら、CREATE TABLE AS を実行する方が
> > > ひと手間少ないかと思います。
> >
> > ありがとうございます
> >
> > なるほど。
> > CLUSTERってそういう感じになっていたんですね
> > と言う事は、CLUSTERでインデックス指定出来るようになってますけど
> > 処理の早い遅いはあれどインデックス以外の物指定出来ても問題ないわけですね
> > BRINとか任意のカラム指定出来れば良いのに…
> >
> 要は、一行一行を読み出す時に、インデックスの順に従うため、
> B-treeのように大小関係を定義できるインデックスでないとダメという事です。
> 任意のクエリーで作るのであれば、排他ロックをした上で CREATE TABLE AS を
> 実行するのと変わりません。

CLUSTER実行時も、ACCESS EXCLUSIVEロックが確保されるので
インデックスがないので処理に時間が掛かると言う事は置いて置いて
インデックスによるソートでも任意のカラムソートでも、
結果的には同じなのでは無いかと思いました。

> > あれ、そうすると、Ver.9.0あたりでVACUUM FULLがCLUSTER相当の処理に変更っ
> > てありましたけど
> > CLUSTER設定されたテーブルにVACUUM FULLを実行したときって ORDER BYはどう
> > なるのかしら…CLUSTER相当になるのかな
> >
> CLUSTERで物理順がインデックスの通りに並ぶのは、あくまでもCLUSTERを実行した
> 直後ですので、その後、ゴチャゴチャデータが入ってくれば、ゴチャゴチャしてきます。
> (なので、CLUSTER設定された、という状態は存在しません)
> 
> CLUSTER と VACUUM FULL の違いは、元テーブルを読み出す時にインデックスの順に
> 従うか、単に先頭から読み出すか、です。
> 「単に先頭から読み出す」だとどのテーブルに対しても実行でき、新しく作成された
> テーブルにはゴミデータが存在しない(VACUUM FULL実行直後)が、特に物理的な
> 順序は考慮しない形となります。

物理的な順序が保証されるのはCLUSTERが実行された
直後のみというのも理解しております

そういう意味では無く、CLUSTERは初回実行時に
CLUSTER table  USING index; 
と明示的にテーブルとインデックスを指定しなければなりませんが、2回目から
は
CLUSTER;
のみで、前回の条件に基づいて処理されますので、
VACUUM FULLを実行時も、CLUSTERのその条件
CLUSTER table  USING index;  が実行されるのかなと思った次第です
そうであれば、何らかの事情でVACUUM FULLを実行した後CLUSTERを実行しなくて
良いなと思った次第です

ありがとうございました

-- 
NISHIMURA,Yutaka./西村ゆたか <iscream @ nugae.org>




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