From: | Darafei "Komяpa" Praliaskouski <me(at)komzpa(dot)net> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: REINDEX backend filtering |
Date: | 2021-02-24 18:34:59 |
Message-ID: | CAC8Q8tJ5k=nsVXWF+PzG93Q3sEYdunMw1Rgy9LbvvUabY+_QSQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
The PostGIS project needed this from time to time. Would be great if
reindex by opclass can be made possible.
We changed the semantics of btree at least twice (in 2.4 and 3.0), fixed
some ND mixed-dimension indexes semantics in 3.0, fixed hash index on 32
bit arch in 3.0.
On Thu, Dec 3, 2020 at 12:32 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> Hello,
>
> Now that we have the infrastructure to track indexes that might be
> corrupted
> due to changes in collation libraries, I think it would be a good idea to
> offer
> an easy way for users to reindex all indexes that might be corrupted.
>
> I'm attaching a POC patch as a discussion basis. It implements a new
> "COLLATION" option to reindex, with "not_current" being the only accepted
> value. Note that I didn't spent too much efforts on the grammar part yet.
>
> So for instance you can do:
>
> REINDEX (COLLATION 'not_current') DATABASE mydb;
>
> The filter is also implemented so that you could cumulate multiple
> filters, so
> it could be easy to add more filtering, for instance:
>
> REINDEX (COLLATION 'libc', COLLATION 'not_current') DATABASE mydb;
>
> to only rebuild indexes depending on outdated libc collations, or
>
> REINDEX (COLLATION 'libc', VERSION 'X.Y') DATABASE mydb;
>
> to only rebuild indexes depending on a specific version of libc.
>
--
Darafei "Komяpa" Praliaskouski
OSM BY Team - http://openstreetmap.by/
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2021-02-24 18:36:02 | Re: REINDEX backend filtering |
Previous Message | Tom Lane | 2021-02-24 17:14:47 | Re: Bizarre behavior of \w in a regular expression bracket construct |