Adding variables for segment_size, wal_segment_size and block sizes

Started by Bernd Helmlealmost 18 years ago8 messageshackers
Jump to latest
#1Bernd Helmle
mailings@oopsware.de

Now that we have customizable segment sizes for heap and WAL at compilation
time i would like to have some runtime variables to query that information
(besides pg_controldata). I can imagine to have the following names:

segment_size: Reports heap segment size
wal_segment_size: Reports wal segment size
block_size: Available yet
wal_block_size: wal block size

I'd like to implement them if we agree on them

--
Thanks

Bernd

In reply to: Bernd Helmle (#1)
Re: Adding variables for segment_size, wal_segment_size and block sizes

Bernd Helmle wrote:

segment_size: Reports heap segment size
wal_segment_size: Reports wal segment size
block_size: Available yet
wal_block_size: wal block size

+1. We already have block_size in GUC.

--
Euler Taveira de Oliveira
http://www.timbira.com/

#3Bruce Momjian
bruce@momjian.us
In reply to: Bernd Helmle (#1)
Re: Adding variables for segment_size, wal_segment_size and block sizes

Bernd Helmle wrote:

Now that we have customizable segment sizes for heap and WAL at compilation
time i would like to have some runtime variables to query that information
(besides pg_controldata). I can imagine to have the following names:

segment_size: Reports heap segment size
wal_segment_size: Reports wal segment size
block_size: Available yet
wal_block_size: wal block size

I'd like to implement them if we agree on them

Bernd, have you made any progress on this?

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#4Bernd Helmle
mailings@oopsware.de
In reply to: Bruce Momjian (#3)
Re: Adding variables for segment_size, wal_segment_size and block sizes

--On Montag, Juni 30, 2008 18:47:33 -0400 Bruce Momjian <bruce@momjian.us>
wrote:

I'd like to implement them if we agree on them

Bernd, have you made any progress on this?

Here's a patch for this. I'll add it to the commit fest wiki page if it's
okay for you.

--
Thanks

Bernd

Attachments:

add_gucs.patchtext/x-diff; charset=utf-8; name=add_gucs.patchDownload+81-0
#5Simon Riggs
simon@2ndQuadrant.com
In reply to: Bernd Helmle (#4)
Re: Adding variables for segment_size, wal_segment_size and block sizes

On Thu, 2008-07-03 at 16:36 +0200, Bernd Helmle wrote:

--On Montag, Juni 30, 2008 18:47:33 -0400 Bruce Momjian <bruce@momjian.us>
wrote:

I'd like to implement them if we agree on them

Bernd, have you made any progress on this?

Here's a patch for this. I'll add it to the commit fest wiki page if it's
okay for you.

It's small and uncontentious, please add it to the wiki.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

#6Abhijit Menon-Sen
ams@2ndQuadrant.com
In reply to: Bernd Helmle (#4)
Re: Adding variables for segment_size, wal_segment_size and block sizes

At 2008-07-03 16:36:02 +0200, mailings@oopsware.de wrote:

Here's a patch for this.

I reviewed the patch, it basically looks fine. A few quibbles with the
provided documentation:

+         Reports the number of pages which can be stored within a file segment.  
+         The total physical size of a segment file in bytes can be determined by multiplying
+         the <varname>block_size</varname> parameter with <varname>segment_size</varname>.

I would say:

Reports the number of blocks/pages which can be stored within a file
segment. The total size of a segment file in bytes is equal to the
<varname>segment_size</> multiplied by the <varname>block_size</>.

+         Reports the size of a write ahead log disk block.  It is determined by the value
+         of <literal>XLOG_BLCKSZ</> when building the server. The default
+         value is 8192 bytes. <varname>wal_block_size</varname> influences the total physical
+         size of a write ahead log segment. See <xref
+         linkend="guc-wal-segment-size"> for more information.
+        </para>

I'd change "write ahead log disk block" to "WAL disk block". How about
this:

Reports the size of a WAL disk block, as determined by the value of
<literal>XLOG_BLCKSZ</> when compiling the server. The default is
8192 bytes. <varname>wal_block_size</> influences the total size of
a WAL segment file. See <xref linkend="guc-wal-segment-size"> for
more information.

+         Reports the number of pages within a write ahead log segment file. <varname>wal_segment_size</varname> multiplied with <varname>wal_block_size</varname> gives the total physical size of a write ahead
+         log segment file in bytes.

Again, I'd say "WAL" here instead of "write ahead log", because the full
form is clumsy in context. How about this:

Reports the number of pages in a WAL segment file. The total size of
a WAL segment file in bytes is equal to <varname>wal_segment_size</>
multiplied by <varname>wal_block_size</>.

What do you think?

-- ams

#7Simon Riggs
simon@2ndQuadrant.com
In reply to: Bernd Helmle (#4)
Re: Adding variables for segment_size, wal_segment_size and block sizes

On Thu, 2008-07-03 at 16:36 +0200, Bernd Helmle wrote:

--On Montag, Juni 30, 2008 18:47:33 -0400 Bruce Momjian <bruce@momjian.us>
wrote:

I'd like to implement them if we agree on them

Bernd, have you made any progress on this?

Here's a patch for this. I'll add it to the commit fest wiki page if it's
okay for you.

I'm not sure why you've included "access/xlog_internal.h".

All the #defines come from pgconfig.h

Maybe that changed from when you started thinking about this?

Other than that, no other comments. Looks good.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

#8Tom Lane
tgl@sss.pgh.pa.us
In reply to: Abhijit Menon-Sen (#6)
Re: Adding variables for segment_size, wal_segment_size and block sizes

Abhijit Menon-Sen <ams@oryx.com> writes:

At 2008-07-03 16:36:02 +0200, mailings@oopsware.de wrote:

Here's a patch for this.

I reviewed the patch, it basically looks fine. A few quibbles with the
provided documentation:

Applied, with ams' doc changes and some further wordsmithing.

regards, tom lane