On 21 September 2012 08:42, Michael Paquier <michael.paqu...@gmail.com> wrote: > > > On Fri, Sep 21, 2012 at 1:00 PM, Hitoshi Harada <umi.tan...@gmail.com> > wrote: >> >> I'm not familiar with pg_reorg, but I wonder why we need a separate >> program for this task. I know pg_reorg is ok as an external program >> per se, but if we could optimize CLUSTER (or VACUUM which I'm a little >> pessimistic about) in the same way, it's much nicer than having >> additional binary + extension. Isn't it possible to do the same thing >> above within the CLUSTER command? Maybe CLUSTER .. CONCURRENTLY? > > CLUSTER might be more adapted in this case as the purpose is to reorder the > table. > The same technique used by pg_reorg (aka table coupled with triggers) could > lower the lock access of the table. > Also, it could be possible to control each sub-operation in the same fashion > way as CREATE INDEX CONCURRENTLY. > By the way, whatever the operation, VACUUM or CLUSTER used, I got a couple > of doubts: > 1) isn't it be too costly for a core operation as pg_reorg really needs many > temporary objects? Could be possible to reduce the number of objects created > if added to core though... > 2) Do you think the current CLUSTER is enough and are there wishes to > implement such an optimization directly in core?
For me, the Postgres user interface should include * REINDEX CONCURRENTLY * CLUSTER CONCURRENTLY * ALTER TABLE CONCURRENTLY and also that autovacuum would be expanded to include REINDEX and CLUSTER, renaming it to automaint. The actual implementation mechanism for those probably looks something like pg_reorg, but I don't see it as preferable to include the utility directly into core, though potentially some of the underlying code might be. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
