Thread: pgsql: Define a separately configurable XLOG_BLCKSZ symbol for the page
pgsql: Define a separately configurable XLOG_BLCKSZ symbol for the page
From
tgl@postgresql.org (Tom Lane)
Date:
Log Message: ----------- Define a separately configurable XLOG_BLCKSZ symbol for the page size used within WAL files. Historically this was the same as the data file BLCKSZ, but there's no necessary connection, and it's possible that performance gains might ensue from reducing XLOG_BLCKSZ. In any case distinguishing two symbols should improve code clarity. This commit does not actually change the page size, only provide the infrastructure to make it possible to do so. initdb forced because of addition of a field to pg_control. Mark Wong, with some help from Simon Riggs and Tom Lane. Modified Files: -------------- pgsql/doc/src/sgml: runtime.sgml (r1.365 -> r1.366) (http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/runtime.sgml.diff?r1=1.365&r2=1.366) pgsql/src/backend/access/transam: xlog.c (r1.231 -> r1.232) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c.diff?r1=1.231&r2=1.232) pgsql/src/bin/pg_controldata: pg_controldata.c (r1.27 -> r1.28) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_controldata/pg_controldata.c.diff?r1=1.27&r2=1.28) pgsql/src/bin/pg_resetxlog: pg_resetxlog.c (r1.40 -> r1.41) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_resetxlog/pg_resetxlog.c.diff?r1=1.40&r2=1.41) pgsql/src/include/access: xlog_internal.h (r1.11 -> r1.12) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/access/xlog_internal.h.diff?r1=1.11&r2=1.12) pgsql/src/include/catalog: pg_control.h (r1.27 -> r1.28) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_control.h.diff?r1=1.27&r2=1.28) pgsql/src/include: pg_config_manual.h (r1.20 -> r1.21) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/pg_config_manual.h.diff?r1=1.20&r2=1.21)
Re: pgsql: Define a separately configurable XLOG_BLCKSZ symbol for the page
From
"Qingqing Zhou"
Date:
"Tom Lane" <tgl@postgresql.org> wrote > xlog.c (r1.231 -> r1.232) > > (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c.diff?r1=1.231&r2=1.232) > Sorry for my after-fact idea ... I noticed this line in the patch: @@ -2708,7 +2708,7 @@ ReadRecord(XLogRecPtr *RecPtr, int emode readId, readSeg, readOff))); goto next_record_is_invalid; } - if (read(readFile, readBuf, BLCKSZ) != BLCKSZ) + if (read(readFile, readBuf, XLOG_BLCKSZ) != XLOG_BLCKSZ) { ereport(emode, (errcode_for_file_access(), This is a patch for write performance, but here theoretically decreases the read performance due to the possible setting of XLOG_BLCKSZ (say 512 as sector size, which is << BLCKSZ). It maybe avoidable by still using BLCKSZ or even more aggresive block size, but may also need some local tweak here. Regards, Qingqing
"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes: > This is a patch for write performance, but here theoretically decreases the > read performance due to the possible setting of XLOG_BLCKSZ (say 512 as > sector size, which is << BLCKSZ). It maybe avoidable by still using BLCKSZ > or even more aggresive block size, but may also need some local tweak here. (1) I really don't think we care that much about read performance on xlog. (2) Buffering should be the kernel's problem, not ours. Since we don't specify O_DIRECT during reading, the kernel ought to be perfectly capable of recognizing the opportunity for read-ahead on these fetches. regards, tom lane