Re: Index bloat of 4x

Поиск
Список
Период
Сортировка
Искать
От
Csaba Nagy
Тема
Re: Index bloat of 4x
Дата
Msg-id
1169457850.2735.20.camel@coppola.muc.ecircle.de
Ответ на
Re: Index bloat of 4x (Jeremy Haile)
Список
Дерево обсуждения
Index bloat of 4x Bill Moran <wmoran@collaborativefusion.com>
Re: Index bloat of 4x "Greg Sabino Mullane" <greg@turnstep.com>
Re: Index bloat of 4x Csaba Nagy <nagy@ecircle-ag.com>
Re: Index bloat of 4x Alvaro Herrera <alvherre@commandprompt.com>
Re: Index bloat of 4x Bill Moran <wmoran@collaborativefusion.com>
Re: Index bloat of 4x Alvaro Herrera <alvherre@commandprompt.com>
Re: Index bloat of 4x Bill Moran <wmoran@collaborativefusion.com>
Re: Index bloat of 4x Tom Lane <tgl@sss.pgh.pa.us>
Re: Index bloat of 4x Bill Moran <wmoran@collaborativefusion.com>
Re: Index bloat of 4x "Ed L." <pgsql@bluepolka.net>
Re: Index bloat of 4x Csaba Nagy <nagy@ecircle-ag.com>
Re: Index bloat of 4x "Ed L." <pgsql@bluepolka.net>
Re: Index bloat of 4x Tom Lane <tgl@sss.pgh.pa.us>
Re: Index bloat of 4x "Jeremy Haile" <jhaile@fastmail.fm>
Re: Index bloat of 4x Csaba Nagy <nagy@ecircle-ag.com>
Re: Index bloat of 4x "Ed L." <pgsql@bluepolka.net>
Re: Index bloat of 4x Bruce Momjian <bruce@momjian.us>
Re: Index bloat of 4x Jim Nasby <decibel@decibel.org>
Re: Index bloat of 4x Alvaro Herrera <alvherre@commandprompt.com>
Re: Index bloat of 4x Bruce Momjian <bruce@momjian.us>
Re: Index bloat of 4x Tom Lane <tgl@sss.pgh.pa.us>
Re: Index bloat of 4x Bruce Momjian <bruce@momjian.us>
Re: Index bloat of 4x Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Re: Index bloat of 4x Vivek Khera <vivek@khera.org>
On Fri, 2007-01-19 at 20:03, Jeremy Haile wrote:
> Is it feasible to add a "reindex concurrently" that doesn't lock the
> table for the rebuild, then locks the table when doing a second pass to
> pickup rows that were changed after the first pass?  Or something like
> that....

IIRC, the objection was the deadlock potential of any lock upgrade, and
the problems of impossible cleanup on failure if something changed the
permissions of the executing user in the meantime. That's why I think it
would make sense if it could be done by a privileged background thread
like the autovacuum ones, so the lock upgrade can be tried without
blocking, as it can take quite some time till it succeeds, and the
cleanup is possible due to the privileged nature of the executor. 

If there would be such a facility it would also need some policies to
control time windows and priorities just as for autovacuum, that's why I
connect it in my usage-focused mind to autovacuum.

Cheers,
Csaba.


В списке pgsql-general по дате отправления
От: Simon Riggs
Дата:
От: Tomasz Ostrowski
Дата:
FAQ