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

From Michael Paquier
Subject Re: remove spurious CREATE INDEX CONCURRENTLY wait
Date
Msg-id 20201110024423.GG1887@paquier.xyz
Whole thread Raw
In response to Re: remove spurious CREATE INDEX CONCURRENTLY wait  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Mon, Nov 09, 2020 at 11:31:15PM -0300, Alvaro Herrera wrote:
> 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.

Hmm.  If you worry about the performance impact here, it is possible
to do a small performance test without this patch.  vacuum_rel() sets
the flag for a non-full VACUUM, so with one backend running a manual
VACUUM in loop on an empty relation could apply some pressure on any
benchmark, even a simple pgbench.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: Hybrid Hash/Nested Loop joins and caching results from subplans
Next
From: Amit Kapila
Date:
Subject: Re: logical streaming of xacts via test_decoding is broken