Re: Disable WAL completely - Performance and Persistency research

Hi,

You were right, the method you described worked well. Thanks you!

But so far, could not get any noticeable improvement in Number of
transactions / latency.

I have tried:
1. At xlog.c, CopyXLogRecordToWAL(int write_len, bool isLogSwitch,
XLogRecData *rdata,
XLogRecPtr StartPos, XLogRecPtr EndPos), Commenting the memcpy syscall:

memcpy(currpos, rdata_data, rdata_len);

2. *XLogInsert(RmgrId rmid, uint8 info), t*he primary insert function in
xloginsert.c.
I tried commenting the following line at this function, so I can return a
phony pointer every time the function is called, just as in bootstrap mode.

*if (IsBootstrapProcessingMode() && rmid != RM_XLOG_ID)*

3. At xlog.c, XLogInsertRecord(XLogRecData *rdata, XLogRecPtr fpw_lsn).
Commenting the WALInsertLock(s), as well as, commenting the spinlocks
around - Update shared LogwrtRqst. (Write, if we crossed page boundary.)

4. The last thing I tried regarding *XLogInsertRecord* function is to
comment:
"/*

* All the record data, including the header, is now ready to be

* inserted. Copy the record in the space reserved.

*/

CopyXLogRecordToWAL(rechdr->xl_tot_len, isLogSwitch, rdata,
StartPos, EndPos);"

Regards,
Netanel

On Mon, Jul 11, 2016 at 8:27 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> On 10 July 2016 at 18:27, Netanel Katzburg <netanel10k(at)gmail(dot)com> wrote:
>
>
>> BUT, both options are not good, as they are stopping me from even running
>> i*nitdb.*
>>
>>
>>
> The easiest path for testing will be to use an unpatched PostgreSQL to
> `initdb` and create a new database. Then start up a patched one that simply
> skips WAL writing against an already-`initdb`'d data directory.
>
> You probably won't be able to safely restart PostgreSQL, but all you're
> doing is performance analsys so one-shot operation on a throw-away data
> directory is probably fine.
>
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>