| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| 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: Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions |
| Date: | 2017-06-07 17:30:58 |
| Message-ID: | CA+TgmoZLHOvgwa_4YT-V5RP8Fp6Bju3RGoJu-=+EQXXPCiz8gg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-06-07 17:34:31 | Re: Effect of changing the value for PARALLEL_TUPLE_QUEUE_SIZE |
| Previous Message | Robert Haas | 2017-06-07 17:25:11 | Re: Parallel Aggregation support for aggregate functions that use transitions not implemented for array_agg |