Adding variables for segment_size, wal_segment_size and block sizes

Started by Bernd Helmleover 17 years ago8 messages
#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)
1 attachment(s)
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
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***************
*** 4759,4764 **** dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
--- 4759,4807 ----
        </listitem>
       </varlistentry>
  
+      <varlistentry id="guc-segment-size" xreflabel="segment_size">
+       <term><varname>segment_size</varname> (<type>integer</type>)</term>
+       <indexterm>
+        <primary><varname>segment_size</> configuration parameter</primary>
+       </indexterm>
+       <listitem>
+        <para>
+         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>.
+        </para>
+       </listitem>
+      </varlistentry>
+ 
+      <varlistentry id="guc-wal-block-size" xreflabel="wal_block_size">
+       <term><varname>wal_block_size</varname> (<type>integer</type>)</term>
+       <indexterm>
+        <primary><varname>wal_block_size</> configuration parameter</primary>
+       </indexterm>
+       <listitem>
+        <para>
+         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>
+       </listitem>
+      </varlistentry>
+ 
+      <varlistentry id="guc-wal-segment-size" xreflabel="wal_segment_size">
+       <term><varname>wal_segment_size</varname> (<type>integer</type>)</term>
+       <indexterm>
+        <primary><varname>wal_segment_size</> configuration parameter</primary>
+       </indexterm>
+       <listitem>
+        <para>
+         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.
+        </para>
+       </listitem>
+      </varlistentry>
+ 
       <varlistentry id="guc-integer-datetimes" xreflabel="integer_datetimes">
        <term><varname>integer_datetimes</varname> (<type>boolean</type>)</term>
        <indexterm>
*** a/src/backend/utils/misc/guc.c
--- b/src/backend/utils/misc/guc.c
***************
*** 29,34 ****
--- 29,35 ----
  #include "access/transam.h"
  #include "access/twophase.h"
  #include "access/xact.h"
+ #include "access/xlog_internal.h"
  #include "catalog/namespace.h"
  #include "commands/async.h"
  #include "commands/prepare.h"
***************
*** 355,360 **** static int	max_function_args;
--- 356,364 ----
  static int	max_index_keys;
  static int	max_identifier_length;
  static int	block_size;
+ static int  segment_size;
+ static int  wal_block_size;
+ static int  wal_segment_size;
  static bool integer_datetimes;
  
  /* should be static, but commands/variable.c needs to get at these */
***************
*** 1731,1736 **** static struct config_int ConfigureNamesInt[] =
--- 1735,1774 ----
  	},
  
  	{
+ 		{"segment_size", PGC_INTERNAL, PRESET_OPTIONS,
+ 		    gettext_noop("Shows the number of pages per disk file."),
+ 		    NULL,
+ 		    GUC_UNIT_BLOCKS | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
+ 		},
+ 		&segment_size,
+ 		RELSEG_SIZE,
+ 		RELSEG_SIZE,
+ 		RELSEG_SIZE, NULL, NULL
+ 	},
+ 
+ 	{
+ 		{"wal_block_size", PGC_INTERNAL, PRESET_OPTIONS,
+ 			gettext_noop("Shows the write ahead log block size."),
+ 			NULL,
+ 			GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
+ 		},
+ 		&wal_block_size,
+ 		XLOG_BLCKSZ, XLOG_BLCKSZ, XLOG_BLCKSZ, NULL, NULL
+ 	},
+ 
+ 	{
+ 		{"wal_segment_size", PGC_INTERNAL, PRESET_OPTIONS,
+ 			gettext_noop("Shows the number of pages per write ahead log segment."),
+ 			NULL,
+ 			GUC_UNIT_XBLOCKS | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
+ 		},
+ 		&wal_segment_size,
+ 		(XLOG_SEG_SIZE / XLOG_BLCKSZ), 
+ 		(XLOG_SEG_SIZE / XLOG_BLCKSZ), 
+ 		(XLOG_SEG_SIZE / XLOG_BLCKSZ), NULL, NULL
+ 	},
+ 
+ 	{
  		{"autovacuum_naptime", PGC_SIGHUP, AUTOVACUUM,
  			gettext_noop("Time to sleep between autovacuum runs."),
  			NULL,
#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

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