Re: Initial 9.2 pgbench write results

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Initial 9.2 pgbench write results
Дата
Msg-id CA+U5nM++qk8VKxbe4GWyhwDBedkFr8NPmeuAYWSg=o7Ojwsw6Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Initial 9.2 pgbench write results  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Initial 9.2 pgbench write results  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Feb 27, 2012 at 5:13 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Feb 24, 2012 at 5:35 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On Thu, Feb 23, 2012 at 11:59 PM, Robert Haas <robertmhaas@gmail.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.

That isn't the case. We have evidence that the current knobs are
hugely ineffective in some cases.

Turning the bgwriter off is hardly "adjusting a setting", its
admitting that there is no useful setting.

I've suggested changes that aren't possible by tuning the current knobs.


> 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.

The split was essential to avoid the bgwriter action being forcibly
turned off during checkpoint sync. The fact that forcibly turning it
off is in some cases a benefit doesn't alter the fact that it was in
many cases a huge negative. If its on you can always turn it off, but
if it was not available at all there was no tuning option. I see no
negative aspect to the split.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Speed dblink using alternate libpq tuple storage
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: CLOG contention, part 2