Robert Haas <robertmh...@gmail.com> wrote: > Simon Riggs <si...@2ndquadrant.com> wrote: >> Robert Haas <robertmh...@gmail.com> wrote: >>> Simon Riggs <si...@2ndquadrant.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
