Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>>> Let's commit the change to 32.
>>>
>>> I would like to do that, but I think we need to at least figure
>>> out a way to provide an escape hatch for people without much
>>> shared memory. We could do that, perhaps, by using a formula
>>> like this:
>>>
>>> 1 CLOG buffer per 128MB of shared_buffers, with a minimum of 8
>>> and a maximum of 32
If we go with such a formula, I think 32 MB would be a more
appropriate divisor than 128 MB. Even on very large machines where
32 CLOG buffers would be a clear win, we often can't go above 1 or 2
GB of shared_buffers without hitting latency spikes due to overrun
of the RAID controller cache. (Now, that may change if we get DW
in, but that's not there yet.) 1 GB / 32 is 32 MB. This would
leave CLOG pinned at the minimum of 8 buffers (64 KB) all the way up
to shared_buffers of 256 MB.
>> Let's just use a constant value for clog buffers until the
>> low-memory patch arrives.
> Tom already stated that he found that unacceptable. Unless he
> changes his opinion, we're not going to get far if you're only
> happy if it's constant and he's only happy if there's a formula.
>
> On the other hand, I think there's a decent argument that he
> should change his opinion, because 192kB of memory is not a lot.
> However, what I mostly want is something that nobody hates, so we
> can get it committed and move on.
I wouldn't hate it either way, as long as the divisor isn't too
large.
-Kevin