| From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: REINDEX CONCURRENTLY 2.0 |
| Date: | 2017-03-03 02:44:49 |
| Message-ID: | 3ed671c8-0b03-e42a-710e-b50bb91b79fe@proxel.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 03/02/2017 02:25 AM, Jim Nasby wrote:
> On 2/28/17 11:21 AM, Andreas Karlsson wrote:
>> The only downside I can see to this approach is that we no logner will
>> able to reindex catalog tables concurrently, but in return it should be
>> easier to confirm that this approach can be made work.
>
> Another downside is any stored regclass fields will become invalid.
> Admittedly that's a pretty unusual use case, but it'd be nice if there
> was at least a way to let users fix things during the rename phase
> (perhaps via an event trigger).
Good point, but I agree with Andres here. Having REINDEX CONCURRENTLY
issue event triggers seems strange to me. While it does create and drop
indexes as part of its implementation, it is actually just an index
maintenance job.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-03-03 03:11:52 | Re: Performance degradation in TPC-H Q18 |
| Previous Message | Robert Haas | 2017-03-03 02:40:52 | Re: Adding support for Default partition in partitioning |