Re: Redesigning checkpoint_segments

From: Venkata Balaji N <nag1010(at)gmail(dot)com>
To: Petr Jelinek <petr(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Redesigning checkpoint_segments
Date: 2015-02-22 10:03:08
Message-ID: CAEyp7J_vTNEy+64p=scwb8akpPU7CT0W=Tw_QhWtYFZHgbVzWg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> I am wondering a bit about interaction with wal_keep_segments.
> One thing is that wal_keep_segments is still specified in number of
> segments and not size units, maybe it would be worth to change it also?
> And the other thing is that, if set, the wal_keep_segments is the real
> max_wal_size from the user perspective (not from perspective of the
> algorithm in this patch, but user does not really care about that) which is
> somewhat weird given the naming.

In my opinion -

I think wal_keep_segments being number of segments would help a lot. In my
experience, while handling production databases, to arrive at an optimal
value for wal_keep_segments, we go by calculating number of segments
getting generated in wal archive destination (hourly or daily basis), this
would further help us calculate how many segments to keep considering
various other factors in an replication environment to ensure master has
enough WALs in pg_xlog when standby comes back up after the outage.

Ofcourse, if we can calculate number-of-segments, we can calculate the same
in terms of size too. Calculating number of segments would be more
feasible.

Regards,
VBN

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2015-02-22 10:33:16 Re: hash agg is slower on wide tables?
Previous Message Andrew Gierth 2015-02-22 09:59:56 Re: Abbreviated keys for Numeric