Horton

Re: Add parallelism and glibc dependent only options to reindexdb

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Peter Eisentraut <peter.eisentraut@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-12T05:57:17Z
Lists: pgsql-hackers 
On Fri, Jul 12, 2019 at 07:49:13AM +0200, Julien Rouhaud wrote:
> It shouldn't be a problem, I reused the same infrastructure as for
> vacuumdb.  so run_reindex_command has a new "async" parameter, so when
> there's no parallelism it's using executeMaintenanceCommand (instead
> of PQsendQuery) which will block until query completion.  That's why
> there's no isFree usage at all in this case.

My point is more about consistency and simplification with the case
where n > 1 and that we could actually move the async/sync code paths
into the same banner as the async mode waits as well until a slot is
free, or in short when the query completes.
--
Michael

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/