| From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
|---|---|
| To: | Ants Aasma <ants(at)cybertec(dot)at> |
| 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:38:44 |
| Message-ID: | 51DA96B4.2040609@vmware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 08.07.2013 13:21, Ants Aasma wrote:
> 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.
GetXLogBuffer() doesn't read the content of the page - it writes to it
(or rather, the caller of GetXLogBarrier() does). The barrier is needed
between reading xlblocks (to check that the buffer contains the right
page), and writing the WAL data to the buffer. README.barrier says that
you need a full memory barrier to separate a load and a store.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-07-08 10:43:27 | Re: XLogInsert scaling, revisited |
| Previous Message | Amit Kapila | 2013-07-08 10:36:11 | Re: Reduce maximum error in tuples estimation after vacuum. |