Re: XLogInsert scaling, revisited - Mailing list pgsql-hackers

From Ants Aasma
Subject Re: XLogInsert scaling, revisited
Date
Msg-id CA+CSw_ucP1PY_0kFWDmaS3_VzcG4cmrZTV9UZY2F17jUp_4mvQ@mail.gmail.com
Whole thread Raw
In response to Re: XLogInsert scaling, revisited  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Wed, May 29, 2013 at 8:40 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> Thanks for asking :-). I've been fixing bitrot throughout the winter. I just
> started cleaning it up again last week, and also continued with performance
> testing.
>
> Unfortunately I lost the 8-core box I used earlier to test this, to disk
> failure, so I can't repeat the tests I ran earlier. However, I have access
> to a new 32-core box, the attached results are from that.

The results look great!

Is this 32 physical cores or with hyperthreading? If the former, then
did you profile what is behind the sublinear scaling at concurrency
>8?

Shouldn't the pg_write_barrier in AdvanceXLInsertBuffer be
complemented with pg_read_barrier after reading the value of xlblocks
in GetXLogBuffer? It might not be needed if some other action is
providing the barrier, but in that case I think it deserves a comment
why it's not needed so future refactorings don't create a data race.

Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: pg_dump with postgis extension dumps rules separately
Next
From: Peter Eisentraut
Date:
Subject: units in postgresql.conf comments