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.
I'm still not very happy with any of the options here. BAS is great if you didn't want to trash the cache, but its also annoying to people that really did want to load a large table into cache. However we set it, we're going to have problems because not everybody has the same database. We're trying to guess which data is in memory and which is on disk and then act accordinly. The answer to that question cannot be answered solely by how big shared_buffers is. It really ought to be a combination of (at least) shared_buffers and total database size. I think we must either put some more intelligence into the setting of the threshold, or give it to the user as a parameter, possibly as a parameter not mentioned in the sample .conf. If we set the threshold unintelligently or in a way that cannot be overridden, we will still get weird bug reports from people who set shared_buffers higher and got a performance drop. We need to make a final decision on this quickly, so I'll say no more on this for 8.3 to help that process. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(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
