Gaetano Mendola <[EMAIL PROTECTED]> 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: Tweak
planner and executor to avoid doing ExecProject() in table scan
nodes where it's not really necessary. In many cases where the
scan node is not the topmost plan node (eg, joins, aggregation),
it's possible to just return the table tuple directly instead of
generating an intermediate projection tuple. In preliminary
testing, this reduced the CPU time needed for 'SELECT COUNT(*) FROM
foo' by about 10%.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
