Heikki Linnakangas wrote:
> In any case, I'd like to see more test results before we make a
> decision. I'm running tests with DBT-2 and a seq scan running in the
> background to see if the cache-spoiling effect shows up. I'm also trying
> to get hold of some bigger hardware to run on. Running these tests takes
> some calendar time, but the hard work has already been done. I'm going
> to start reviewing Jeff's synchronized scans patch now.
Here are the results of the DBT-2 tests:
http://community.enterprisedb.com/seqscan/imola/
In each of these tests, at the end of rampup a script is started that
issues a "SELECT COUNT(*) FROM stock" in a loop, with 2 minute delay
between end of previous query and start of next one.
The patch makes the seq scans go significantly faster. In the 1 hour
test period, the patched tests perform roughly 30-100% as many selects
as unpatched tests.
With 100 and 105 warehouses, it also significantly reduces the impact of
the seq scan on other queries; response times are lower with the patch.
With 120 warehouses the reduction of impact is not as clear, but when
you plot the response times it's still there (the plots on the "response
times charts"-page are useless because they're overwhelmed by the
checkpoint spike).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com