Re: Initial 9.2 pgbench write results

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Initial 9.2 pgbench write results
Date: 2012-02-27 05:13:15
Message-ID: CA+TgmoYVxUz_bAqoiZg5hBzA57ouBb+N0u9bVUtCUxWZekhDVw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 24, 2012 at 5:35 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Thu, Feb 23, 2012 at 11:59 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> this doesn't feel like the right time to embark on a bunch of new
>> engineering projects.
>
> IMHO this is exactly the right time to do full system tuning. Only
> when we have major projects committed can we move towards measuring
> things and correcting deficiencies.

Ideally we should measure things as we do them. Of course there will
be cases that we fail to test which slip through the cracks, as Greg
is now finding, and I agree we should try to fix any problems that we
turn up during testing. But, as I said before, so far Greg hasn't
turned up anything that can't be fixed by adjusting settings, so I
don't see a compelling case for change on that basis.

As a side point, there's no obvious reason why the problems Greg is
identifying here couldn't have been identified before committing the
background writer/checkpointer split. The fact that we didn't find
them then suggests to me that we need to be more not less cautious in
making further changes in this area.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-02-27 06:23:48 Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Previous Message Robert Haas 2012-02-27 04:59:11 Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)