From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Support for REINDEX CONCURRENTLY |
Date: | 2013-02-13 06:55:23 |
Message-ID: | CAB7nPqTFq=wzHDC2pjW9rGRQeqkzbx9vu3G3Lfsy0CrZU_cuEw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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,
On Tue, Feb 12, 2013 at 10:04 PM, Andres Freund <andres(at)2ndquadrant(dot)com>wrote:
> On 2013-02-12 21:54:52 +0900, Michael Paquier wrote:
> > > 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.
>
> What I proposed above wouldn't need the case where toastrelidx =
> InvalidOid, so no need to worry about that.
>
> > 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.
>
> Sure. This just seems easier as it really only requires changes inside
> 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
Attachment | Content-Type | Size |
---|---|---|
20130213_reindex_concurrently_v10.patch | application/octet-stream | 77.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2013-02-13 07:38:17 | review: ALTER ROLE ALL SET |
Previous Message | David E. Wheeler | 2013-02-13 05:37:57 | Re: JSON Function Bike Shedding |