Re: BUG #13484: Performance problem with logical decoding - Mailing list pgsql-bugs

From olivier.gosseaume@free.fr
Subject Re: BUG #13484: Performance problem with logical decoding
Date
Msg-id 1293293691.18410087.1436255750706.JavaMail.root@zimbra72-e12.priv.proxad.net
Whole thread Raw
In response to Re: BUG #13484: Performance problem with logical decoding  (olivier.gosseaume@free.fr)
Responses Re: BUG #13484: Performance problem with logical decoding  (Andres Freund <andres@anarazel.de>)
List pgsql-bugs
Hi Andres

>>The fix is just to change
>>        if (fd == -1 || XLByteInSeg(change->lsn, curOpenSegNo))
>>into
>>        if (fd == -1 || !XLByteInSeg(change->lsn, curOpenSegNo))
>>
>>the bug doesn't have any correctness implications afaics, just
>>performance. We read all the spilled files till the end, so even change
>>spilled to the wrong segment gets picked up.
>
>Great. I will try to rebuild on Windows with this patch and let you know

You got it :)

I rebuilt postgres 9.4.4 x64 this morning with your patch in reorderbuffer.c and now it FLIES (140mS for a transaction
with4096 inserts, 600mS for 40960 inserts).  

Spilling to disk is now very fast as expected (not even noticeable).

Thanks for your great support.

Will this patch be included in 9.4.5 ?

PS: the build process on Windows is very simple and straightforward, congrats.

Best regards,
Olivier

pgsql-bugs by date:

Previous
From: sshang@pivotal.io
Date:
Subject: BUG #13489: pg_attribute.attndims turns to 0 when 'create table like/as'
Next
From: Petr Jelinek
Date:
Subject: Re: BUG #13126: table constraint loses its comment