Re: pg_reorg in core?

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_reorg in core?
Date: 2012-09-21 13:42:45
Message-ID: CAB7nPqQnxXR9ORpgFHZOaqrebT8h9_PxvCysXM6GkiqYn-KVow@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 21, 2012 at 1:00 PM, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)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?
--
Michael Paquier
http://michael.otacoo.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-09-21 14:30:57 Re: 64-bit API for large object
Previous Message Michael Paquier 2012-09-21 13:32:32 Re: pg_reorg in core?