Re: [HACKERS] increasing the default WAL segment size - Mailing list pgsql-hackers

From Beena Emerson
Subject Re: [HACKERS] increasing the default WAL segment size
Date
Msg-id CAOG9ApESjqYm2VQWxNrZAKySzVo-vDw2JWhDqYQStzD+gwRUiA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] increasing the default WAL segment size  (Beena Emerson <memissemerson@gmail.com>)
Responses Re: [HACKERS] increasing the default WAL segment size  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
List pgsql-hackers
Hello,
PFA the updated patches.

On Fri, Jan 27, 2017 at 2:17 PM, Beena Emerson <memissemerson@gmail.com> wrote:
Hello Andres,

Thank you for your review.

On Fri, Jan 27, 2017 at 12:39 AM, Andres Freund <andres@anarazel.de> wrote:
Hi,

On 2017-01-23 11:35:11 +0530, Beena Emerson wrote:
> Please find attached an updated WIP patch. I have incorporated almost all
> comments. This is to be applied over Robert's patches. I will post
> performance results later on.
>
> 1. shift (>>) and AND (&) operations: The assign hook of wal_segment_size
> sets the WalModMask and WalShiftBit. All the modulo and division operations
> using XLogSegSize has been replaced with these. However, there are many
> preprocessors which divide with XLogSegSize in xlog_internal.h. I have not
> changed these because it would mean I will have to reassign the WalShiftBit
> along with XLogSegSize in all the modules which use these macros. That does
> not seem to be a good idea. Also, this means shift operator can be used
> only in couple of places.

I think it'd be better not to have XLogSegSize anymore. Silently
changing a macros behaviour from being a compile time constant to
something runtime configurable is a bad idea.

I dont think I understood u clearly. You mean convert the macros using XLogSegSize to functions?

I have moved the ModMask related changes to a separate patch  01-add-XLogSegmentOffset-macro.patch. This creates the macro XLogSegmentOffset and replaces all "% XLogSegSize" and "% XLOG_SEG_SIZE" with this macro.
I have not included the shift operator because the changes only apply to about 4 lines did not give any performance boost or such.

Hm. Are GUC hooks a good way to compute the masks?  Interdependent GUCs
are unfortunately not working well, and several GUCs might end up
depending on these.  I think it might be better to assign the variables
somewhere early in StartupXLOG() or such.

I am not sure about these interdependent GUCs. I need to study this better and make changes as required.


The process flow is such thatthe Control File which sets the XLogSegSIze is read after the GUC options are initialized. StartupXLOG is called by StartupProcessMain() which restores the XLOG and then exits. Hence he value initialised here are not persistent throughout the postgres run. It throws error during pg_ctl stop.
The XLogSegSize adjustment in assign hooks have been removed and a new macro ConvertToXSegs is used to convert the min and max wal_size to the segment count when required. wal_segment_size set from ReadControlFile also affects the Checkpointsegment value and hence the assign_wal_segment_size calls CalculateCheckpointSegments.
 
Documentation is updated


Performance Tests:

I ran pgbench tests for different wal segment size on database of scale factor 300 with shared_buffers of 8GB. Each of the tests ran for 10 min and a median of 3 readings were considered. The following table shows the performance of the patch wrt the HEAD for different client count for various wal-segsize value. We could say that there is not performance difference.

163264128





8MB-1.360.020.43-0.24
16MB-0.380.18-0.090.4
32MB-0.520.290.390.59
64MB-0.150.040.520.38



--
Thank you, 

Beena Emerson

Have a Great Day!
Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY
Next
From: Robert Treat
Date:
Subject: Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY