Re: remove spurious CREATE INDEX CONCURRENTLY wait - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: remove spurious CREATE INDEX CONCURRENTLY wait
Date
Msg-id 20201110023115.GA18579@alvherre.pgsql
Whole thread Raw
In response to Re: remove spurious CREATE INDEX CONCURRENTLY wait  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: remove spurious CREATE INDEX CONCURRENTLY wait  (Michael Paquier <michael@paquier.xyz>)
Re: remove spurious CREATE INDEX CONCURRENTLY wait  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2020-Nov-09, Tom Lane wrote:

> Michael Paquier <michael@paquier.xyz> writes:
> > On Mon, Nov 09, 2020 at 08:32:13PM -0500, Tom Lane wrote:
> >> Do we really need exclusive lock on the ProcArray to make this flag
> >> change?  That seems pretty bad from a concurrency standpoint.
> 
> > Any place where we update vacuumFlags acquires an exclusive LWLock on
> > ProcArrayLock.  That's held for a very short time, so IMO it won't
> > matter much in practice, particularly if you compare that with the
> > potential gains related to the existing wait phases.
> 
> Not sure I believe that it doesn't matter much in practice.  If there's
> a steady stream of shared ProcArrayLock acquisitions (for snapshot
> acquisition) then somebody wanting exclusive lock will create a big
> hiccup, whether they hold it for a short time or not.

Yeah ... it would be much better if we can make it use atomics instead.
Currently it's an uint8, and in PGPROC itself it's probably not a big
deal to enlarge that, but I fear that quadrupling the size of the
mirroring array in PROC_HDR might be bad for performance.  However,
maybe if we use atomics to access it, then we don't need to mirror it
anymore?  That would need some benchmarking of GetSnapshotData.




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Avoiding useless SHA256 initialization with backup manifests, breaking base backups with FIPS
Next
From: Andy Fan
Date:
Subject: Re: Hybrid Hash/Nested Loop joins and caching results from subplans