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?? 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. 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. 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. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate