Great.  Based on this, do you have a patch that is ready to apply.


Heikki Linnakangas wrote:
> 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:
> 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
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

  Bruce Momjian  <[EMAIL PROTECTED]>

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(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

Reply via email to