Re: [HACKERS] avoid bloat from CREATE INDEX CONCURRENTLY

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] avoid bloat from CREATE INDEX CONCURRENTLY
Дата
Msg-id 1983.1488288643@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] avoid bloat from CREATE INDEX CONCURRENTLY  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: [HACKERS] avoid bloat from CREATE INDEX CONCURRENTLY  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> On 28 February 2017 at 13:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Um ... isn't there a transaction boundary there anyway?

> Yes, the patch releases the snapshot early, so it does not hold it
> once the build scan has completed. This allows the sort and build
> phases to occur without holding back the xmin.

Oh ... so Alvaro explained it badly.  The reason this is specific to
btree is that it's the only AM with any significant post-scan building
time.

However, now that I read the patch: this is a horribly ugly hack.
I really don't like the API (if it even deserves the dignity of that
name) that you've added to snapmgr.  I supposwe the zero documentation
for it fits in nicely with the fact that it's a badly-thought-out kluge.

I think it would be better to just move the responsibility for snapshot
popping in this sequence to the index AMs, full stop.
        regards, tom lane



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

Предыдущее
От: Jan Michálek
Дата:
Сообщение: Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki
Следующее
От: Pavan Deolasee
Дата:
Сообщение: [HACKERS] Skip all-visible pages during second HeapScan of CIC