On Tue, 2006-12-19 at 17:43 +0000, Simon Riggs wrote: > On Tue, 2006-12-19 at 09:07 -0800, Jeff Davis wrote: > > I have updated my Synchronized Scan patch and have had more time for > > testing. > > > > Go to http://j-davis.com/postgresql/syncscan-results10.html > > where you can download the patch, and see the benchmarks that I've run. > > > > The results are very promising. I did not see any significant slowdown > > for non-concurrent scans or for scans that fit into memory, although I > > do need more testing in this area. > > Yes, very promising. > > Like to see some tests with 2 parallel threads, since that is the most > common case. I'd also like to see some tests with varying queries, > rather than all use select count(*). My worry is that these tests all > progress along their scans at exactly the same rate, so are likely to > stay in touch. What happens when we have significantly more CPU work to > do on one scan - does it fall behind??
Right, that's important. Hopefully the test you describe below sheds some light on that. > I'd like to see all testing use log_executor_stats=on for those > sessions. I would like to know whether the blocks are being hit while > still in shared_buffers or whether we rely on the use of the full > filesystem buffer cache to provide performance. Ok, will do. > It would be very cool to run a background performance test also, say a > pgbench run with a -S 100. That would show us what its like to try to > run multiple queries when most of the cache is full with something else. Do you mean '-S -s 100' or '-s 100'? Reading the pgbench docs it doesn't look like '-S' takes an argument. > It would be better to have a GUC to control the scanning > e.g. > synch_scan_threshold = 256MB > > rather than link it to effective_cache_size always, since that is > related to index scan tuning. I will make it completely unrelated to effective_cache_size. I'll do the same with "sync_scan_start_offset" (by the way, does someone have a better name for that?). Regards, Jeff Davis ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org