Re: Adding variables for segment_size, wal_segment_size and block sizes

Lists: pgsql-hackers
From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Adding variables for segment_size, wal_segment_size and block sizes
Date: 2008-05-15 14:56:23
Message-ID: 62739BFA3F6B80F2E1B5BC99@imhotep.credativ.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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


From: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding variables for segment_size, wal_segment_size and block sizes
Date: 2008-05-17 15:14:58
Message-ID: 482EF672.8060008@timbira.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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/


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding variables for segment_size, wal_segment_size and block sizes
Date: 2008-06-30 22:47:33
Message-ID: 200806302247.m5UMlXk26647@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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


From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding variables for segment_size, wal_segment_size and block sizes
Date: 2008-07-03 14:36:02
Message-ID: 79636C5E324155408C7FA171@imhotep.credativ.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

--On Montag, Juni 30, 2008 18:47:33 -0400 Bruce Momjian <bruce(at)momjian(dot)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

Attachment Content-Type Size
add_gucs.patch text/x-diff 4.2 KB

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding variables for segment_size, wal_segment_size and block sizes
Date: 2008-07-04 09:48:03
Message-ID: 1215164883.4051.45.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On Thu, 2008-07-03 at 16:36 +0200, Bernd Helmle wrote:
> --On Montag, Juni 30, 2008 18:47:33 -0400 Bruce Momjian <bruce(at)momjian(dot)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


From: Abhijit Menon-Sen <ams(at)oryx(dot)com>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding variables for segment_size, wal_segment_size and block sizes
Date: 2008-07-08 03:45:29
Message-ID: 20080708034529.GA19229@toroid.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

At 2008-07-03 16:36:02 +0200, mailings(at)oopsware(dot)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


From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding variables for segment_size, wal_segment_size and block sizes
Date: 2008-07-08 06:50:47
Message-ID: 1215499847.4051.668.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On Thu, 2008-07-03 at 16:36 +0200, Bernd Helmle wrote:
> --On Montag, Juni 30, 2008 18:47:33 -0400 Bruce Momjian <bruce(at)momjian(dot)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


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Abhijit Menon-Sen <ams(at)oryx(dot)com>
Cc: Bernd Helmle <mailings(at)oopsware(dot)de>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding variables for segment_size, wal_segment_size and block sizes
Date: 2008-07-10 22:09:13
Message-ID: 19103.1215727753@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Abhijit Menon-Sen <ams(at)oryx(dot)com> writes:
> At 2008-07-03 16:36:02 +0200, mailings(at)oopsware(dot)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