On Mon, 2008-01-28 at 16:21 -0500, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > Rather than having a boolean GUC, we should have a number and make the > > parameter "synchronised_scan_threshold". > > This would open up a can of worms I'd prefer not to touch, having to do > with whether the buffer-access-strategy behavior should track that or > not. As the note in heapam.c says, > > * If the table is large relative to NBuffers, use a bulk-read access > * strategy and enable synchronized scanning (see syncscan.c). Although > * the thresholds for these features could be different, we make them the > * same so that there are only two behaviors to tune rather than four. > > It's a bit late in the cycle to be revisiting that choice. Now we do > already have three behaviors to worry about (BAS on and syncscan off) > but throwing in a randomly settable knob will take it back to four, > and we have no idea how that fourth case will behave. The other tack we > could take (having the one GUC variable control both thresholds) is > not good since it will result in pg_dump trashing the buffer cache.
OK, good points. I'm still concerned that the thresholds gets higher as we increase shared_buffers. We may be removing performance features as fast as we gain performance when we set shared_buffers higher. Might we agree that the threshold should be fixed at 8MB, rather than varying upwards as we try to tune? The objective of having a tuning hook would have been simply to normalise the effects of increasing shared_buffers anyway, so fixing it would solve the problem I see. (8MB is the default, based upon 25% of 32MB). -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
