From: | Netanel Katzburg <netanel10k(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Disable WAL completely - Performance and Persistency research |
Date: | 2016-07-11 11:14:51 |
Message-ID: | CAFN9q6QuNa0Nn7+-7hi3j59OQ2z1xwqUKL_PAUVQUtMiGXJ1jg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-07-11 11:26:59 | Re: BUG #14230: Wrong timeline returned by pg_stop_backup on a standby |
Previous Message | Kyotaro HORIGUCHI | 2016-07-11 10:07:22 | Re: asynchronous and vectorized execution |