, size of PGPROC remains
> > aligned. So, probably effect is related to distance between PGPROC
> > members...
> > See comparison of 16-bytes alignment of PGXACT + reduce PGXACT access
> > padding of PGPROC.
> My earlier testing had showed t
Amit Kapila wrote on 06/07/2017 07:34:06 AM:
> > The down side is that on smaller configurations (single socket) where
> > is less "lock thrashing" in the storage subsystem and there are
> > Lwlocks to take for an exclusive acquire, there is a
Robert Haas wrote on 06/07/2017 12:12:02 PM:
> > OK -- would love the feedback and any suggestions on how to mitigate
> > end problems.
> Did you intend to attach a patch?
Yes I do -- tomorrow or Thursday -- needs a little cleaning up ...
> > Sokolov Yura has
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 ...
> > > Sokolov Yura has a patch which, to me, looks good for pgbench rw
> > > performance. Does
ed this issue. If so it would be great to
learn the solution.
5 июня 2017 г. 10:30 PM пользователь Jim Van Fleet <vanfl...@us.ibm.com>
I have been experimenting with splitting the ProcArrayLock into parts.
That is, to Acquire the ProcArrayLock in shared mode, it is only
I left out the retry in LWLockAcquire.
Description: Binary data
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription:
subsystem 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.
NP, Sokolov --
pgsql-hackers-ow...@postgresql.org wrote on 06/05/2017 03:26:46 PM:
> From: Sokolov Yura <y.soko...@postgrespro.ru>
> To: Jim Van Fleet <vanfl...@us.ibm.com>
> Cc: firstname.lastname@example.org
> Date: 06/05/2017 03:28 PM
> Subject: Re: [HACKE
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.
- 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
> > because in one environment (one socket) it was 6% down and over 15% up
> > the right environment (two sockets).
> > S
> The Enterprise PostgreSQL Company
> [attachment "shm-mq-less-spinlocks-v1.2.patch" deleted by Jim Van
> Sent via pgsql-hacke
pgsql-hackers-ow...@postgresql.org wrote on 11/06/2017 09:47:22 AM:
> From: Andres Freund <and...@anarazel.de>
> Please don't top-quote on postgresql lists.
> On 2017-11-06 09:44:24 -0600, Jim Van Fleet wrote:
> > > >hammerdb
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?
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> >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?
> Sent from my Android device with K-9 Mail. Please excuse my
Mail list logo