Horton

Re: Add parallelism and glibc dependent only options to reindexdb

Julien Rouhaud <rjuju123@gmail.com>

View thread View on postgr.es
From: Julien Rouhaud <rjuju123@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Thomas Munro <thomas.munro@gmail.com>, Daniel Verite <daniel@manitou-mail.org>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Kevin Grittner <kgrittn@gmail.com>
Date: 2019-07-05T17:25:41Z
Lists: pgsql-hackers 
On Fri, Jul 5, 2019 at 6:16 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
>
> On 2019-07-02 10:30, Julien Rouhaud wrote:
> > That's a great idea, and would make the parallelism in reindexdb much
> > simpler.  There's however a downside, as users won't have a way to
> > benefit from index filtering until they upgrade to this version.  OTOH
> > glibc 2.28 is already there, and a hypothetical fancy reindexdb is far
> > from being released.
>
> Isn't that also the case for your proposal?  We are not going to release
> a new reindexdb before a new REINDEX.

Sure, but my point was that once the new reindexdb is released (or if
you're so desperate, using a nightly build or compiling your own), it
can be used against any previous major version.  There is probably a
large fraction of users who don't perform a postgres upgrade when they
upgrade their OS, so that's IMHO also something to consider.

Commits

  1. Add support for --jobs in reindexdb

  2. Remove more progname references in vacuumdb.c

  3. Refactor parallelization processing code in src/bin/scripts/