From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improving connection scalability: GetSnapshotData() |
Date: | 2020-03-30 14:04:00 |
Message-ID: | CAPpHfdthCaCt09Nnj6oCYq93_PUfJSw5QOLGgnid3qJsEWXuGA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Mar 29, 2020 at 9:50 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On March 29, 2020 11:24:32 AM PDT, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> > clearly a big win on majority
> >of workloads, I think we still need to investigate different workloads
> >on different hardware to ensure there is no regression.
>
> Definitely. Which workloads are you thinking of? I can think of those affected facets: snapshot speed, commit speed with writes, connection establishment, prepared transaction speed. All in the small and large connection count cases.
Following pgbench scripts comes first to my mind:
1) SELECT txid_current(); (artificial but good for checking corner case)
2) Single insert statement (as example of very short transaction)
3) Plain pgbench read-write (you already did it for sure)
4) pgbench read-write script with increased amount of SELECTs. Repeat
select from pgbench_accounts say 10 times with different aids.
5) 10% pgbench read-write, 90% of pgbench read-only
> I did measurements on all of those but prepared xacts, fwiw
Great, it would be nice to see the results in the thread.
> That definitely needs to be measured, due to the locking changes around procarrayaddd/remove.
>
> I don't think regressions besides perhaps 2pc are likely - there's nothing really getting more expensive but procarray add/remove.
I agree that ProcArrayAdd()/Remove() should be first subject of
investigation, but other cases should be checked as well IMHO.
Regarding 2pc I can following scenarios come to my mind:
1) pgbench read-write modified so that every transaction is prepared
first, then commit prepared.
2) 10% of 2pc pgbench read-write, 90% normal pgbench read-write
3) 10% of 2pc pgbench read-write, 90% normal pgbench read-only
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2020-03-30 14:09:33 | Re: Make autovacuum sort tables in descending order of xid_age |
Previous Message | Alexey Kondratov | 2020-03-30 14:00:01 | Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line |