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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Avoiding useless SHA256 initialization with backup manifests, breaking base backups with FIPS
Следующее
От: Andy Fan
Дата:
Сообщение: Re: Hybrid Hash/Nested Loop joins and caching results from subplans