On 10/06/2014 04:42 AM, Michael Paquier wrote:
> On Fri, Oct 3, 2014 at 9:51 PM, Heikki Linnakangas <hlinnakangas@vmware.com>
> wrote:
>> So I now have a refactoring patch ready that I'd like to commit (the
> attached two patches together), but to be honest, I have no idea why the
> second patch is so essential to performance.
> Thanks. I did some more tests with master, master+patch1, master+patch1+CRC
> refactoring, but I am not able to see any performance difference with
> pgbench (--no-vacuum, -t) and the test suite you provided, just some noise
> that barely changed performance.
Thanks for the confirmation. I'm really going crazy with benchmarking
this. Sometimes I see a big difference, the next day it's gone.
> Note that fd.c uses
> SYNC_METHOD_FSYNC_WRITETHROUGH, so it is necessary to include xlog.h in it.
Ah, thanks! You mentioned that before, but I didn't see it because my
laptop doesn't HAVE_FSYNC_WRITETHROUGH. Fixed now.
Attached is a new version of the first, refactoring-only patch. Notable
changes since last version:
* Fixed XLogSaveBufferForHint. It didn't initialize BkpBlock struct,
rendering it completely broken.
* Moved XLogSaveBufferForHint, log_newpage and log_newpage_buffer to
xloginsert.c. XLogSaveBufferForHint needs to share the XLogFillBkpBlock
function with the rest of the code in xloginsert.c, so this allows
keeping it static. And it makes sense anyway - those are high-level
functions, comparable to XLogInsert, not low-level stuff related to
managing WAL itself.
Barring objections, I'll commit this, and then continue benchmarking the
second patch with the WAL format and API changes.
- Heikki