Re: Should we cacheline align PGXACT? - Mailing list pgsql-hackers

From Jim Van Fleet
Subject Re: Should we cacheline align PGXACT?
Date
Msg-id OF3F555BBE.6E290E21-ON862580F7.007F3DD2-862580F7.00801F02@notes.na.collabserv.com
Whole thread Raw
In response to Re: Should we cacheline align PGXACT?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers

pgsql-hackers-owner@postgresql.org wrote on 04/03/2017 01:58:03 PM:

> From: Andres Freund <andres@anarazel.de>

> To: Alexander Korotkov <a.korotkov@postgrespro.ru>
> Cc: David Steele <david@pgmasters.net>, Ashutosh Sharma
> <ashu.coek88@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, Alvaro
> Herrera <alvherre@2ndquadrant.com>, Robert Haas
> <robertmhaas@gmail.com>, Bernd Helmle <mailings@oopsware.de>, Tomas
> Vondra <tomas.vondra@2ndquadrant.com>, pgsql-hackers <pgsql-
> hackers@postgresql.org>

> Date: 04/03/2017 01:59 PM
> Subject: Re: [HACKERS] Should we cacheline align PGXACT?
> Sent by: pgsql-hackers-owner@postgresql.org
>
> On 2017-03-25 19:35:35 +0300, Alexander Korotkov wrote:
> > On Wed, Mar 22, 2017 at 12:23 AM, David Steele <david@pgmasters.net> wrote:
> >
> > > Hi Alexander
> > >
> > > On 3/10/17 8:08 AM, Alexander Korotkov wrote:
> > >
> > > Results look good for me.  Idea of committing both of patches looks
> > >> attractive.
> > >> We have pretty much acceleration for read-only case and small
> > >> acceleration for read-write case.
> > >> I'll run benchmark on 72-cores machine as well.
> > >>
> > >
> > > Have you had a chance to run those tests yet?
> > >
> >
> > I discovered an interesting issue.
> > I found that ccce90b3 (which was reverted) gives almost same effect as
> > PGXACT alignment on read-only test on 72-cores machine.
>
> That's possibly because it changes alignment?
>
>
> > That shouldn't be related to the functionality of ccce90b3 itself, because
> > read-only test don't do anything with clog.  And that appears to be true.
> > Padding of PGPROC gives same positive effect as ccce90b3.  Padding patch
> > (pgproc-pad.patch) is attached.  It's curious that padding changes size of
> > PGPROC from 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 earlier testing had showed that padding everything is the best
> approach :/
>

My approach has been to, generally, pad "everything" as well.  In my testing on power, I padded  PGXACT to 16 bytes.  To my surprise, with the padding in isolation, the performance (on hammerdb) was slightly degraded.

Jim Van Fleet
>
> I'm inclined to push this to the next CF, it seems we need a lot more
> benchmarking here.
>
> Greetings,
>
> Andres Freund
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
>
http://www.postgresql.org/mailpref/pgsql-hackers
>

pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Variable substitution in psql backtick expansion
Next
From: Vaishnavi Prabakaran
Date:
Subject: Re: PATCH: Batch/pipelining support for libpq