Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflicttracking in serializable transactions

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflicttracking in serializable transactions
Дата
Msg-id CA+TgmoZLHOvgwa_4YT-V5RP8Fp6Bju3RGoJu-=+EQXXPCiz8gg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling fromrw-conflict tracking in serializable transactions  ("Mengxing Liu" <liu-mx15@mails.tsinghua.edu.cn>)
Ответы Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling fromrw-conflict tracking in serializable transactions  ("Mengxing Liu" <liu-mx15@mails.tsinghua.edu.cn>)
Список pgsql-hackers
On Tue, Jun 6, 2017 at 12:16 PM, Mengxing Liu
<liu-mx15@mails.tsinghua.edu.cn> wrote:
> I think disk I/O is not the bottleneck in our experiment, but the global lock is.

A handy way to figure this kind of thing out is to run a query like
this repeatedly during the benchmark:

SELECT wait_event_type, wait_event FROM pg_stat_activity;

I often do this by using psql's \watch command, often \watch 0.5 to
run it every half-second.  I save all the results collected during the
benchmark using 'script' and then analyze them to see which wait
events are most frequent.  If your theory is right, you ought to see
that SerializableXactHashLock occurs as a wait event very frequently.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Parallel Aggregation support for aggregate functionsthat use transitions not implemented for array_agg
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Effect of changing the value for PARALLEL_TUPLE_QUEUE_SIZE