Re: Support for REINDEX CONCURRENTLY
От | Michael Paquier |
---|---|
Тема | Re: Support for REINDEX CONCURRENTLY |
Дата | |
Msg-id | CAB7nPqTFq=wzHDC2pjW9rGRQeqkzbx9vu3G3Lfsy0CrZU_cuEw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Support for REINDEX CONCURRENTLY (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Support for REINDEX CONCURRENTLY
|
Список | pgsql-hackers |
Hi,
Please find attached a new version of the patch incorporating the 2 fixes requested:
- Fix for to insert new data to multiple toast indexes in toast_save_datum if necessary
- Fix the lock wait phase with new function WaitForMultipleVirtualLocks allowing to perform a wait on multiple locktags at the same time. WaitForVirtualLocks uses also WaitForMultipleVirtualLocks but on a single locktag.
I am still looking at the approach removing reltoastidxid, approach more complicated but cleaner than what is currently done in the patch.
Regards,
--
Michael
Please find attached a new version of the patch incorporating the 2 fixes requested:
- Fix for to insert new data to multiple toast indexes in toast_save_datum if necessary
- Fix the lock wait phase with new function WaitForMultipleVirtualLocks allowing to perform a wait on multiple locktags at the same time. WaitForVirtualLocks uses also WaitForMultipleVirtualLocks but on a single locktag.
I am still looking at the approach removing reltoastidxid, approach more complicated but cleaner than what is currently done in the patch.
Regards,
On Tue, Feb 12, 2013 at 10:04 PM, Andres Freund <andres@2ndquadrant.com> wrote:
On 2013-02-12 21:54:52 +0900, Michael Paquier wrote:What I proposed above wouldn't need the case where toastrelidx =
> > Changing only toast_save_datum:
> >
> > [... code ...]
> >
> Yes, I have spent a little bit of time looking at the code related to
> retoastindxid and thought about this possibility. It would make the changes
> far easier with the existing patch, it will also be necessary to update the
> catalog pg_statio_all_tables to make the case where OID is InvalidOid
> correct with this catalog.
InvalidOid, so no need to worry about that.Sure. This just seems easier as it really only requires changes inside
> However, I do not think it is as clean as simply
> removing retoastindxid and have all the toast APIs running consistent
> operations, aka using only RelationGetIndexList.
toast_save_datum() and which mostly avoids any overhead (not even
additional palloc()s) if there is only one index.
That would lower the burden of proof that no performance regressions
exist (which I guess would be during querying) and the amount of
possibly external breakage due to removing the field...
Not sure whats the best way to do this when committing. But I think you
could incorporate something like the proposed to continue working on the
patch. It really should only take some minutes to incorporate it.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Michael
Вложения
В списке pgsql-hackers по дате отправления: