Re: pg_reorg in core?

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pg_reorg in core?
Дата
Msg-id CAB7nPqQnxXR9ORpgFHZOaqrebT8h9_PxvCysXM6GkiqYn-KVow@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_reorg in core?  (Hitoshi Harada <umi.tanuki@gmail.com>)
Ответы Re: pg_reorg in core?  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers


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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_reorg in core?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 64-bit API for large object