Re: open items for 9.4

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Geoghegan <pg(at)heroku(dot)com>, "Claudio Freire" <klaussfreire(at)gmail(dot)com>, "David E(dot) Wheeler" <david(at)justatheory(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Jan Wieck <jan(at)wi3ck(dot)info>
Subject: Re: open items for 9.4
Date: 2014-09-30 11:56:24
Message-ID: 542A9A68.6080202@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09/29/2014 11:41 PM, Andres Freund wrote:
> On 2014-09-29 16:35:12 -0400, Tom Lane wrote:
>> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
>>> On 2014-09-29 16:16:38 -0400, Tom Lane wrote:
>>>> I wonder why it's a fixed constant at all, and not something like
>>>> "wal_buffers / 8".
>>
>>> Because that'd be horrible performancewise on a system with many
>>> wal_buffers. There's several operations where all locks are checked in
>>> sequence (to see whether there's any stragglers that need to finish
>>> inserting) and even some where they're acquired concurrently (e.g. for
>>> xlog switch, checkpoint and such).
>>
>> Hm. Well, if there are countervailing considerations as to how large is a
>> good value, that makes it even less likely that it's sensible to expose
>> it as a user tunable.
>
> Aren't there such considerations for most of the performance critical
> gucs?
>
>> A relevant analogy is that we don't expose a way
>> to adjust the number of lock table partitions at runtime.
>
> Which has worked out badly for e.g. the number of buffer partitions...

Number of buffer partitions is the analogy I've also had in mind. It has
worked out pretty well, IMHO. Sure, with a system with a lot of CPUs you
sometimes want to increase the hardwired default, but most
configurations are not too sensitive to it.

No-one has stepped up to do any testing on the effects if the GUC during
the beta period, while the GUC has been there. Somehow I don't think
anyone's going to do any rigorous tuning of it before commissioning a
system into production, either.

This might come up again in 9.5 cycle, once we get the improvements in
LWLock and buffer cache scalability. That can make scalability of the
WAL insertion more visible again.

There seems to be no decisive consensus here. I'm going to put my foot
on the ground and go remove it, as I'm leaning towards that option, and
we need to get the release out. But if someone objects loudly enough to
actually write the documentation and commit it that way, I'm happy with
that too.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2014-09-30 12:03:35 Re: Patch to support SEMI and ANTI join removal
Previous Message Graeme B. Bell 2014-09-30 11:34:48 Re: Yet another abort-early plan disaster on 9.3