Gaetano Mendola <mendola@bigfoot.com> writes:
> The select take long:
> Postgres7.3.3: average 4000 ms
> Postgres7.4b2: average 2600 ms
> you can experiment your self with the dump that I gave you
Hm. I tried to duplicate your results. I'm getting about 5400 msec
versus 4200 msec, which is a nice version-to-version improvement but
not as large as you're seeing. (I have --enable-cassert on, though,
and that may be cancelling some of the percentage gain.)
It looks like most of the speedup is in the seq scan step. I think
it is probably due to this change:
2003-02-03 10:07 tgl
* src/: backend/executor/execMain.c, backend/executor/execScan.c,backend/executor/nodeIndexscan.c,
backend/executor/nodeSeqscan.c,backend/executor/nodeTidscan.c,backend/optimizer/plan/createplan.c,backend/optimizer/plan/planner.c,
backend/optimizer/util/plancat.c,backend/optimizer/util/relnode.c,include/executor/executor.h,include/nodes/relation.h,
include/optimizer/plancat.h:Tweakplanner and executor to avoid doing ExecProject() in table scannodes where it's not
reallynecessary. In many cases where thescan node is not the topmost plan node (eg, joins, aggregation),it's
possibleto just return the table tuple directly instead ofgenerating an intermediate projection tuple. In
preliminarytesting,this reduced the CPU time needed for 'SELECT COUNT(*) FROMfoo' by about 10%.
regards, tom lane
