From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: REINDEX backend filtering |
Date: | 2021-02-26 09:47:38 |
Message-ID: | CABUevEwO972yCxAWhFVFW64U6Oog=N9QvN+Xeux-2S9BNwMU1w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 16, 2020 at 1:27 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Dec 15, 2020 at 06:34:16PM +0100, Magnus Hagander wrote:
> > Is this really a common enough operation that we need it in the main grammar?
> >
> > Having the functionality, definitely, but what if it was "just" a
> > function instead? So you'd do something like:
> > SELECT 'reindex index ' || i FROM pg_blah(some, arguments, here)
> > \gexec
> >
> > Or even a function that returns the REINDEX commands directly (taking
> > a parameter to turn on/off concurrency for example).
> >
> > That also seems like it would be easier to make flexible, and just as
> > easy to plug into reindexdb?
>
> Having control in the grammar to choose which index to reindex for a
> table is very useful when it comes to parallel reindexing, because
> it is no-brainer in terms of knowing which index to distribute to one
> job or another. In short, with this grammar you can just issue a set
> of REINDEX TABLE commands that we know will not conflict with each
> other. You cannot get that level of control with REINDEX INDEX as it
(oops, seems I forgot to reply to this one, sorry!)
Uh, isn't it almost exactly the opposite?
If you do it in the backend grammar you *cannot* parallelize it
between indexes, because you can only run one at a time.
Whereas if you do it in the frontend, you can. Either with something
like reindexdb that could do it automatically, or with psql as a
copy/paste job?
> may be possible that more or more commands conflict if they work on an
> index of the same relation because it is required to take lock also on
> the parent table. Of course, we could decide to implement a
> redistribution logic in all frontend tools that need such things, like
> reindexdb, but that's not something I think we should let the client
> decide of. A backend-side filtering is IMO much simpler, less code,
> and more elegant.
It's simpler in the simple case, i agree with that. But ISTM it's also
a lot less flexible for anything except the simplest case...
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2021-02-26 09:50:25 | Re: REINDEX backend filtering |
Previous Message | Simon Riggs | 2021-02-26 09:36:34 | Re: NOT VALID for Unique Indexes |