Re: Raising the checkpoint_timeout limit

From: Andres Freund <andres(at)anarazel(dot)de>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Raising the checkpoint_timeout limit
Date: 2016-02-04 12:06:10
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2016-02-03 15:07:12 -0600, Jim Nasby wrote:
> On 2/2/16 10:10 PM, Robert Haas wrote:
> >Now, you could also set such configuration settings in
> >a situation where it will not work out well. But that is true of most
> >configuration settings.

By that argument we should probably raise the lower limit of a bunch of
parameters :P

> Yeah, if we're going to start playing parent then I think the first thing to
> do is remove the fsync GUC. The AWS team has done testing that shows it to
> be worthless from a performance standpoint now that we have synchronous
> commit, and it's an extremely large foot-bazooka to have laying around.

Meh, I don't buy that. There are workloads where that's the case, but
also ones were it's not true. Try e.g. 2PC. And yes, there's definitely
cases where 2PC makes sense, even if you don't need durability on a
local basis.


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2016-02-04 12:24:21 Re: WAL logging problem in 9.4.3?
Previous Message Amit Kapila 2016-02-04 12:00:35 Re: [PATCH] Refactoring of LWLock tranches