From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Julien Rouhaud <rjuju123@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Kevin Grittner <kgrittn@gmail.com>
Subject: Re: Add parallelism and glibc dependent only options to reindexdb
Date: Mon, 01 Jul 2019 10:10:51 -0400
Message-ID: <26518.1561990251@sss.pgh.pa.us> (raw)
In-Reply-To: <20190701085453.GA1388@paquier.xyz>
References: <CAOBaU_YrnH_Jqo46NhaJ7uRBiWWEcS40VNRQxgFbqYo9kApUsg@mail.gmail.com>
<20190701085453.GA1388@paquier.xyz>
Michael Paquier <michael@paquier.xyz> writes:
> - 0003 begins to be the actual fancy thing with the addition of a
> --jobs option into reindexdb. The main issue here which should be
> discussed is that when it comes to reindex of tables, you basically
> are not going to have any conflicts between the objects manipulated.
> However if you wish to do a reindex on a set of indexes then things
> get more tricky as it is necessary to list items per-table so as
> multiple connections do not conflict with each other if attempting to
> work on multiple indexes of the same table. What this patch does is
> to select the set of indexes which need to be worked on (see the
> addition of cell in ParallelSlot), and then does a kind of
> pre-planning of each item into the connection slots so as each
> connection knows from the beginning which items it needs to process.
> This is quite different from vacuumdb where a new item is distributed
> only on a free connection from a unique list. I'd personally prefer
> if we keep the facility in parallel.c so as it is only
> execution-dependent and that we have no pre-planning. This would
> require keeping within reindexdb.c an array of lists, with one list
> corresponding to one connection instead which feels more natural.
Couldn't we make this enormously simpler and less bug-prone by just
dictating that --jobs applies only to reindex-table operations?
> - 0004 is the part where the concurrent additions really matter as
> this consists in applying an extra filter to the indexes selected so
> as only the glibc-sensitive indexes are chosen for the processing.
I think you'd be better off to define and document this as "reindex
only collation-sensitive indexes", without any particular reference
to a reason why somebody might want to do that.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, michael@paquier.xyz, rjuju123@gmail.com, pgsql-hackers@lists.postgresql.org, kgrittn@gmail.com
Subject: Re: Add parallelism and glibc dependent only options to reindexdb
In-Reply-To: <26518.1561990251@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox