Our hardware/software configuration:
kernel: 2.5.74
distro: RH7.2
pgsql:  7.3.3
CPUS:   8
MHz:    700.217
model:  Pentium III (Cascades)
memory: 8298888 kB
shmmax: 3705032704

We did several sets of runs(repeating runs with the same database
parameters) and have the following observation:

1. With everything else the same, we did two run sets with
small effective_cache_size (default=1000) and large (655360 i.e. 5GB
or 60% of the system memory 8GB).  It seems to me that small 
effective_cache_size favors the choice of nested loop joins (NLJ) 
while the big effective_cache_size is in favor of merge joins (MJ).  
We thought the large effective_cache_size should lead us to better 
plans. But we found the opposite. 

Three plans out of 22 are different.  Two of those plans are worse 
in execution time by 2 times and 8 times.   For example, one plan, 
that included  NLJ ran in 4 seconds but the other, switching to an 
MJ, ran in  32 seconds.  Please refer to the link at the end of 
this mail for the query and plans.  Did we miss something, or 
improvements are needed for the optimizer?

2. Thanks to all the response we got from this mailing list, we 
decided to use SETSEED(0) default_statistics_target=1000 to reduce 
the variation.   We get now the exact the same execution plans 
and costs with repeated runs and that reduced the variation a lot.
However, within the same run set consist of 6 runs, we see 2-3% 
standard deviation for the run metrics associated with the multiple
stream part of the test (as opposed to the single stream part).

We would like to reduce the variation to be less than 1% so that a 
2% change between two different kernels would be significant. 
Is there anything else we can do?

query: http://developer.osdl.org/~jenny/11.sql
plan with small effective_cache_size: 
plan with large effective_cache_size: 


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to