Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Maybe we need to split this into two pieces, given Tom's legitimate
> concern about semaphore use. How about we increase the allowed range for
> shared_buffers and max_fsm_pages, as proposed in my patch, and leave the
> max_connections issue on the table? I also wondered if instead of first
> setting max_connections and then shared_buffers/max_fsm_pages, we should
> try to scale them in synch somehow.
The existing initdb code actually does try to scale them in sync to some
extent --- take a closer look at the arguments being passed during the
max-connections test phase. It won't choose a large max_connections
unless it can simultaneously get 5 times that many shared_buffers.
I think this probably needs to be more aggressive though. In a
situation of limited SHMMAX it's probably more important to keep
shared_buffers as high as we can than to get a high max_connections.
We could think about increasing the 5x multiplier, adding Min and/or Max
limits, or some combination.
BTW, I fat-fingered the calculations I was doing last night --- the
actual shmem consumption in CVS tip seems to be more like 17K per
max_connection increment, assuming max_locks_per_connection = 64.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
