| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Support for REINDEX CONCURRENTLY |
| Date: | 2012-10-05 21:07:03 |
| Message-ID: | 20121005210703.GB5769@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane escribió:
> Note that allowing subsequent requests to jump the queue would not be a
> good fix for this; if you do that, it's likely the ex-lock will never be
> granted, at least not till the next system idle time. Which if you've
> got one, you don't need a feature like this at all; you might as well
> just reindex normally during your idle time.
Not really. The time to run a complete reindex might be several hours.
If the idle time is just a few minutes or seconds long, it may be more
than enough to complete the switch operation, but not to run the
complete reindex.
Maybe another idea is that the reindexing is staged: the user would
first run a command to create the replacement index, and leave both
present until the user runs a second command (which acquires a strong
lock) that executes the switch. Somehow similar to a constraint created
as NOT VALID (which runs without a strong lock) which can be later
validated separately.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-10-05 21:14:02 | Re: Support for REINDEX CONCURRENTLY |
| Previous Message | Tom Lane | 2012-10-05 20:03:29 | Re: Support for REINDEX CONCURRENTLY |