Simon Riggs <simon@2ndquadrant.com> writes:
> We already hit that issue and fixed it early in the 8.3 cycle. It was
> more of a problem than the checkpoint issue because it caused hard
> lock-outs while the file switches occurred. It didn't show up unless you
> looked at the very detailed transaction result data because on fast
> systems we are file switching every few seconds.

> Not seen any gains from varying the WAL file size since then...

I think the use-case for varying the WAL segment size is unrelated to
performance of the master server, but would instead be concerned with
adjusting the granularity of WAL log shipping.

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

On Sat, 03 May 2008 13:14:35 -0400 Tom Lane wrote:

> Simon Riggs <simon@2ndquadrant.com> writes:
>
> > Not seen any gains from varying the WAL file size since then...
>
> I think the use-case for varying the WAL segment size is unrelated to
> performance of the master server, but would instead be concerned with
> adjusting the granularity of WAL log shipping.

*nod* I heard this argument several times. Simon: there was a discussion
about this topic in Prato last year. Since WAL logfiles are usually
binary stuff, the files can't be compressed much so a smaller logfile
size on a not-so-much-used system would save a noticeable amount of
bandwith (and cpu cycles for compression).


Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Andreas 'ads' Scherbaum wrote:
> On Sat, 03 May 2008 13:14:35 -0400 Tom Lane wrote:
>
> > Simon Riggs <simon@2ndquadrant.com> writes:
> >
> > > Not seen any gains from varying the WAL file size since then...
> >
> > I think the use-case for varying the WAL segment size is unrelated to
> > performance of the master server, but would instead be concerned with
> > adjusting the granularity of WAL log shipping.
>
> *nod* I heard this argument several times. Simon: there was a discussion
> about this topic in Prato last year. Since WAL logfiles are usually
> binary stuff, the files can't be compressed much so a smaller logfile
> size on a not-so-much-used system would save a noticeable amount of
> bandwith (and cpu cycles for compression).

Seems the stuff to zero out the unused segment tail would be more useful
here.

Kevin sent me the source file some time ago -- he didn't want to upload
them to pgfoundry because he was missing a Makefile. I built one for
him, but last time I looked he hadn't uploaded anything.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

On Mon, 5 May 2008 11:09:32 -0400 Alvaro Herrera wrote:

> Andreas 'ads' Scherbaum wrote:
> > On Sat, 03 May 2008 13:14:35 -0400 Tom Lane wrote:
> >
> > > Simon Riggs <simon@2ndquadrant.com> writes:
> > >
> > > > Not seen any gains from varying the WAL file size since then...
> > >
> > > I think the use-case for varying the WAL segment size is unrelated to
> > > performance of the master server, but would instead be concerned with
> > > adjusting the granularity of WAL log shipping.
> >
> > *nod* I heard this argument several times. Simon: there was a discussion
> > about this topic in Prato last year. Since WAL logfiles are usually
> > binary stuff, the files can't be compressed much so a smaller logfile
> > size on a not-so-much-used system would save a noticeable amount of
> > bandwith (and cpu cycles for compression).
>
> Seems the stuff to zero out the unused segment tail would be more useful
> here.

Yeah, that was the original question, if i remember correctly.
If the WAL logfile is zeroed out just before start using it and PG only
needs a small part of this logfile, the remaining zeroes are easily
compressable. Useful for PITR and good for backups/rsync/scp.


Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Alvaro Herrera <alvherre@commandprompt.com> writes:
>> On Sat, 03 May 2008 13:14:35 -0400 Tom Lane wrote:
>>> I think the use-case for varying the WAL segment size is unrelated to
>>> performance of the master server, but would instead be concerned with
>>> adjusting the granularity of WAL log shipping.

> Seems the stuff to zero out the unused segment tail would be more useful
> here.

Well, that's also useful, but it hardly seems like a substitute for
picking a more optimal segment size in the first place.

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

On Mon, 2008-05-05 at 13:06 -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> >> On Sat, 03 May 2008 13:14:35 -0400 Tom Lane wrote:
> >>> I think the use-case for varying the WAL segment size is unrelated to
> >>> performance of the master server, but would instead be concerned with
> >>> adjusting the granularity of WAL log shipping.
>
> > Seems the stuff to zero out the unused segment tail would be more useful
> > here.
>
> Well, that's also useful, but it hardly seems like a substitute for
> picking a more optimal segment size in the first place.

I can't imagine having separately compiled executables depending upon
the write rate of different applications. What would you do if the write
rate increases over time (like it usually does)? How would you manage a
server farm like that? There's no practical answer there, just a great
way to introduce instability where there previously wasn't any.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com


--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches