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

Thank you very much! I follow your advice and here is the result.

SerializableXactHashLock 73
predicate_lock_manager 605
WALWriteLock 3
SerializableFinishedListLock 665

There are more than 90 events each time. SerializableXactHashLock/SerializableFinishedListLock are both used in SSI.
I think that's why PG is so slow in high contention environment.

> -----Original Messages-----
> From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
> Sent Time: 2017-06-08 01:30:58 (Thursday)
> To: "Mengxing Liu" <liu-mx15(at)mails(dot)tsinghua(dot)edu(dot)cn>
> Cc: kgrittn <kgrittn(at)gmail(dot)com>, "Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
> Subject: Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions
>
> On Tue, Jun 6, 2017 at 12:16 PM, Mengxing Liu
> <liu-mx15(at)mails(dot)tsinghua(dot)edu(dot)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
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
Mengxing Liu