From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: REINDEX filtering in the backend |
Date: | 2019-09-04 11:54:53 |
Message-ID: | a81069b1-fdaa-ff40-436e-7840bd639ccf@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-08-30 02:10, Michael Paquier wrote:
> On Thu, Aug 29, 2019 at 10:52:55AM +0200, Julien Rouhaud wrote:
>> That was already suggested by Thomas and seconded by Peter E., see
>> https://www.postgresql.org/message-id/2b1504ac-3d6c-11ec-e1ce-3daf132b3d37%402ndquadrant.com.
>>
>> I personally think that it's a sensible approach, and I'll be happy to
>> propose a patch for that too if no one worked on this yet.
>
> That may be interesting to sort out first then because we'd likely
> want to know what is first in the catalogs before designing the
> filtering processing looking at it, no?
Right. We should aim to get per-object collation version tracking done.
And then we might want to have a REINDEX variant that processes exactly
those indexes with an out-of-date version number -- and then updates
that version number once the reindexing is done. I think that project
is achievable for PG13.
I think we can keep this present patch in our back pocket for, say, the
last commit fest if we don't make sufficient progress on those other
things. Right now, it's hard to review because the target is moving,
and it's unclear what guidance to give users.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2019-09-04 12:01:42 | Re: [HACKERS] CLUSTER command progress monitor |
Previous Message | Dilip Kumar | 2019-09-04 11:51:36 | Re: block-level incremental backup |