Re: remove spurious CREATE INDEX CONCURRENTLY wait
От | Alvaro Herrera |
---|---|
Тема | Re: remove spurious CREATE INDEX CONCURRENTLY wait |
Дата | |
Msg-id | 20201110023115.GA18579@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: remove spurious CREATE INDEX CONCURRENTLY wait (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: remove spurious CREATE INDEX CONCURRENTLY wait
Re: remove spurious CREATE INDEX CONCURRENTLY wait |
Список | 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 по дате отправления: