| From: | Ants Aasma <ants(at)cybertec(dot)at> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: XLogInsert scaling, revisited |
| Date: | 2013-05-30 00:46:00 |
| Message-ID: | CA+CSw_ucP1PY_0kFWDmaS3_VzcG4cmrZTV9UZY2F17jUp_4mvQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, May 29, 2013 at 8:40 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2013-05-30 01:59:10 | units in postgresql.conf comments |
| Previous Message | Joe Conway | 2013-05-29 22:55:46 | Re: pg_dump with postgis extension dumps rules separately |