x_6-ZyGFPdLCdb8Jr7QJHrJIbUJO1z6oi-JHO8Htk&m=-
>
I8r3tfguIVgEpNumrjWTKOGkJWIbHQNT2M2-02-8cU&s=39p2vefOiiZS9ZooPYkZ97U66hw5osqmkCGcikgZCik&e=
> The Enterprise PostgreSQL Company
> [attachment "shm-mq-less-spinlocks-v1.2.patch" deleted by Jim Van
> Fleet/Austin/Contr/I
Andres Freund wrote on 11/05/2017 03:40:15 PM:
hammerdb, in this configuration, runs a variant of tpcc
>
> What query(s) did you measure?
>
> Andres
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
correct
> >hammerdb, in this configuration, runs a variant of tpcc
>
> Hard to believe that any of the changes here are relevant in that
> case - this is parallelism specific stuff. Whereas tpcc is oltp, right?
>
> Andres
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevi
Hi --
pgsql-hackers-ow...@postgresql.org wrote on 11/06/2017 09:47:22 AM:
> From: Andres Freund
>
> Hi,
>
> Please don't top-quote on postgresql lists.
Sorry
>
> On 2017-11-06 09:44:24 -0600, Jim Van Fleet wrote:
> > > >hammerdb, in this
rom 816 bytes to 848 bytes. So, size of PGPROC remains
16-byte
> > aligned. So, probably effect is related to distance between PGPROC
> > members...
> >
> > See comparison of 16-bytes alignment of PGXACT + reduce PGXACT access
vs.
> > padding of PGPROC.
>
> My ear
system and there are
multiple Lwlocks to take for an exclusive acquire, there is a decided
downturn in performance. On hammerdb, the prototype was 6% worse than the
base on a single socket power configuration.
If there is interest in this approach, I will submit a patch.
Jim
NP, Sokolov --
pgsql-hackers-ow...@postgresql.org wrote on 06/05/2017 03:26:46 PM:
> From: Sokolov Yura
> To: Jim Van Fleet
> Cc: pgsql-hackers@postgresql.org
> Date: 06/05/2017 03:28 PM
> Subject: Re: [HACKERS] HACKERS[PROPOSAL] split ProcArrayLock into
> multiple part
ristic to use one part on light loads and two on
heavy (and still stay correct), then I don't see it ... With the
combination, what I think we would see is awesome pgbench rw, awesome
hammerdb 2 socket performance, and degraded single socket hammerdb.
Jim
From: Sokolov Yura
To:
Amit Kapila wrote on 06/07/2017 07:34:06 AM:
...
> > The down side is that on smaller configurations (single socket) where
there
> > is less "lock thrashing" in the storage subsystem and there are
multiple
> > Lwlocks to take for an exclusive acquire, there is a decided downturn
in
> > perfor
Robert Haas 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, l
pgsql-hackers-ow...@postgresql.org wrote on 06/07/2017 04:06:57 PM:
...
> >
> > Did you intend to attach a patch?
> Yes I do -- tomorrow or Thursday -- needs a little cleaning up ...
meant Friday
>
> > > Sokolov Yura has a patch which, to me, looks good for pgbench rw
> > > performance. Does n
I left out the retry in LWLockAcquire.
ProcArrayLock_part.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
would be "exactly" the same as no parts and
hence no degradation in the single socket environment -- and with 2, you
get some positive performance.
Jim
- Forwarded by Jim Van Fleet/Austin/Contr/IBM on 09/21/2017 03:37 PM
-
pgsql-hackers-ow...@postgresql.org wrote on 06/09/2017 0
> On 2017-09-21 15:51:54 -0500, Jim Van Fleet wrote:
> > Not to beat on a dead horse, or anything, but this fix was frowned
upon
> > because in one environment (one socket) it was 6% down and over 15% up
in
> > the right environment (two sockets).
>
> > S
14 matches
Mail list logo
