| From: | "Jim Van Fleet" <vanfleet(at)us(dot)ibm(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: HACKERS[PROPOSAL] split ProcArrayLock into multiple parts |
| Date: | 2017-06-07 21:06:57 |
| Message-ID: | OF5861AEF0.509D5D54-ON86258138.0061478F-86258138.0073FED2@notes.na.collabserv.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> wrote on 06/07/2017 12:12:02 PM:
> > OK -- would love the feedback and any suggestions on how to mitigate
the low
> > end problems.
>
> Did you intend to attach a patch?
Yes I do -- tomorrow or Thursday -- needs a little cleaning up ...
> > Sokolov Yura has a patch which, to me, looks good for pgbench rw
> > performance. Does not do so well with hammerdb (about the same as
base) on
> > single socket and two socket.
>
> Any idea why? I think we will have to understand *why* certain things
> help in some situations and not others, not just *that* they do, in
> order to come up with a good solution to this problem.
Looking at the data now -- LWLockAquire philosophy is different -- at
first glance I would have guessed "about the same" as the base, but I can
not yet explain why we have super pgbench rw performance and "the same"
hammerdb performance.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Regina Obe | 2017-06-07 21:07:10 | Re: PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity |
| Previous Message | Erik Rijkers | 2017-06-07 21:00:59 | Re: Race conditions with WAL sender PID lookups |