On Mon, 2008-05-05 at 13:06 -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> 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
Alvaro Herrera <[EMAIL PROTECTED]> 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.
>
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 <[EMAIL PROTECTED]> writes:
> > >
> > > > Not seen any gains from varying the WAL file size since then...
> > >
> > > I think th
Andreas 'ads' Scherbaum wrote:
> On Sat, 03 May 2008 13:14:35 -0400 Tom Lane wrote:
>
> > Simon Riggs <[EMAIL PROTECTED]> 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
> > performan
On Sat, 03 May 2008 13:14:35 -0400 Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> 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 c
Simon Riggs <[EMAIL PROTECTED]> 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 r
On Fri, 2008-05-02 at 12:28 -0400, Greg Smith wrote:
> As PostgreSQL makes its way into higher throughput environments, it
> wouldn't surprise me to discover more of these situations where switching
> WAL segments every 16MB turns into a bottleneck.
We already hit that issue and fixed it early
"Mark Wong" <[EMAIL PROTECTED]> writes:
> I saw a that a patch was committed that exposed a configure switch for
> BLCKSZ. I was hoping that I could do that same for XLOG_BLCKSZ. I
> think I got the configure.in, sgml, pg_config_manual.h, and
> pg_config.h.in changes correct.
Applied with minor
On Fri, May 2, 2008 at 9:16 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mark Wong" <[EMAIL PROTECTED]> writes:
>
> > I still believe it makes sense to have them separated. I did have
> > some data, which has since been destroyed, that suggested there were
> > some system characterization differen
On Fri, 2 May 2008, Tom Lane wrote:
The case for varying BLCKSZ is marginal already, and I've seen none at
all for varying XLOG_BLCKSZ.
I recall someone on the performance list who felt it useful increase
XLOG_BLCKSZ to support a high-write environment with WAL shipping, just to
make sending
On Fri, 2 May 2008 09:12:32 -0700
"Mark Wong" <[EMAIL PROTECTED]> wrote:
> I still believe it makes sense to have them separated. I did have
> some data, which has since been destroyed, that suggested there were
> some system characterization differences for OLTP workloads with
> PostgreSQL. Le
"Mark Wong" <[EMAIL PROTECTED]> writes:
> I still believe it makes sense to have them separated. I did have
> some data, which has since been destroyed, that suggested there were
> some system characterization differences for OLTP workloads with
> PostgreSQL. Let's hope those disks get delivered
On Fri, May 2, 2008 at 8:50 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mark Wong" <[EMAIL PROTECTED]> writes:
>
> > As someone who has tested varying both those parameters it feels
> > awkward to have a configure option for one and not the other, or vice
> > versa. I have slightly stronger feeli
"Mark Wong" <[EMAIL PROTECTED]> writes:
> As someone who has tested varying both those parameters it feels
> awkward to have a configure option for one and not the other, or vice
> versa. I have slightly stronger feelings for having them both as
> configure options because it's easier to script, b
On Fri, May 2, 2008 at 12:04 AM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
>
> Tom Lane wrote:
>
> > "Mark Wong" <[EMAIL PROTECTED]> writes:
> >
> > > I saw a that a patch was committed that exposed a configure switch for
> > > BLCKSZ. I was hoping that I could do that same for XLOG_BLCKSZ.
> > >
Tom Lane wrote:
"Mark Wong" <[EMAIL PROTECTED]> writes:
I saw a that a patch was committed that exposed a configure switch for
BLCKSZ. I was hoping that I could do that same for XLOG_BLCKSZ.
Well, we certainly *could*, but what's the use-case really? The case
for varying BLCKSZ is marginal a
"Mark Wong" <[EMAIL PROTECTED]> writes:
> I saw a that a patch was committed that exposed a configure switch for
> BLCKSZ. I was hoping that I could do that same for XLOG_BLCKSZ.
Well, we certainly *could*, but what's the use-case really? The case
for varying BLCKSZ is marginal already, and I've
Hi all,
I saw a that a patch was committed that exposed a configure switch for
BLCKSZ. I was hoping that I could do that same for XLOG_BLCKSZ. I
think I got the configure.in, sgml, pg_config_manual.h, and
pg_config.h.in changes correct.
Regards,
Mark
Index: configure
===
18 matches
Mail list logo
