| From: | Ants Aasma <ants(at)cybertec(dot)at> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: XLogInsert scaling, revisited |
| Date: | 2013-07-08 10:21:17 |
| Message-ID: | CA+CSw_vw6+QH90yPZ49batYj9SjDUkK9vWBT0W1PqeN__Aqo0A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 8, 2013 at 12:16 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> Ok, I've committed this patch now. Finally, phew!
Fantastic work!
> I simplified the handling of xlogInsertingAt per discussion, and added the
> memory barrier to GetXLogBuffer(). I ran again the pgbench tests I did
> earlier with the now-committed version of the patch (except for some comment
> changes). The results are here:
I can't see a reason why a full memory barrier is needed at
GetXLogBuffer, we just need to ensure that we read the content of the
page after we check the end pointer from xlblocks. A read barrier is
enough here unless there is some other undocumented interaction. I
don't think it matters for performance, but it seems like good
practice to have the barriers exactly matching the documentation.
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 | Dave Cramer | 2013-07-08 10:23:45 | Re: [HACKERS] JPA + enum == Exception |
| Previous Message | Kohei KaiGai | 2013-07-08 10:19:57 | Re: [v9.4] row level security |