Horton

Re: Add parallelism and glibc dependent only options to reindexdb

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Julien Rouhaud <rjuju123@gmail.com>, Michael Paquier <michael@paquier.xyz>
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>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Kevin Grittner <kgrittn@gmail.com>
Date: 2019-07-09T11:09:38Z
Lists: pgsql-hackers 
On 2019-07-08 21:08, Julien Rouhaud wrote:
> Don't get me wrong, I do agree that implementing filtering in the
> backend is a better design.  What's bothering me is that I also agree
> that there will be more glibc breakage, and if that happens within a
> few years, a lot of people will still be using pg12- version, and they
> still won't have an efficient way to rebuild their indexes.  Now, it'd
> be easy to publish an external tools that does a simple
> parallel-and-glic-filtering reindex tool that will serve that purpose
> for the few years it'll be needed, so everyone can be happy.

You can already do that: Run a query through psql to get a list of
affected tables or indexes and feed those to reindexdb using -i or -t
options.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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/