Re: Disable WAL completely - Performance and Persistency research

Поиск
Список
Период
Сортировка
От Netanel Katzburg
Тема Re: Disable WAL completely - Performance and Persistency research
Дата
Msg-id CAFN9q6QuNa0Nn7+-7hi3j59OQ2z1xwqUKL_PAUVQUtMiGXJ1jg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Disable WAL completely - Performance and Persistency research  (Craig Ringer <craig@2ndquadrant.com>)
Список 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), the 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@2ndquadrant.com> wrote:
On 10 July 2016 at 18:27, Netanel Katzburg <netanel10k@gmail.com> wrote:
 

BUT, both options are not good, as they are stopping me from even running initdb. 



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

В списке pgsql-hackers по дате отправления: