| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: Support for REINDEX CONCURRENTLY |
| Date: | 2013-06-17 13:19:13 |
| Message-ID: | 20130617131913.GG5875@alap2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2013-06-17 09:12:12 -0400, Peter Eisentraut wrote:
> On 6/17/13 8:23 AM, Michael Paquier wrote:
> > As mentionned by Andres, the only thing that the MVCC catalog patch can
> > improve here
> > is the index swap phase (index_concurrent_swap:index.c) where the
> > relfilenode of the
> > old and new indexes are exchanged. Now an AccessExclusiveLock is taken
> > on the 2 relations
> > being swap, we could leverage that to ShareUpdateExclusiveLock with the
> > MVCC catalog
> > access I think.
>
> Without getting rid of the AccessExclusiveLock, REINDEX CONCURRENTLY is
> not really concurrent, at least not concurrent to the standard set by
> CREATE and DROP INDEX CONCURRENTLY.
Well, it still does the main body of work in a concurrent fashion, so I
still don't see how that argument holds that much water. But anyway, the
argument was only whether we could continue reviewing before the mvcc
stuff goes in, not whether it can get committed before.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nicolas Barbier | 2013-06-17 13:33:04 | Re: refresh materialized view concurrently |
| Previous Message | Kevin Grittner | 2013-06-17 13:18:30 | Re: refresh materialized view concurrently |