Old-style OR indexscan slated for destruction
I am about to rip out the code that supports multiple indexscans for OR
conditions inside a single IndexScan plan node. As best I can tell,
the new-style bitmap-OR code is as fast or faster than the old way
even in fully cached test cases (ie, with no allowance for improved
efficiency of disk access). So there's no percentage in maintaining
support for the old way, and getting rid of it will allow simplification
of code and data structures in the planner.
regards, tom lane
On Sun, 24 Apr 2005, Tom Lane wrote:
I am about to rip out the code that supports multiple indexscans for OR
conditions inside a single IndexScan plan node. As best I can tell,
the new-style bitmap-OR code is as fast or faster than the old way
even in fully cached test cases (ie, with no allowance for improved
efficiency of disk access). So there's no percentage in maintaining
support for the old way, and getting rid of it will allow simplification
of code and data structures in the planner.
very good, Tom !
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
I am about to rip out the code that supports multiple indexscans for OR
conditions inside a single IndexScan plan node. As best I can tell,
the new-style bitmap-OR code is as fast or faster than the old way
even in fully cached test cases (ie, with no allowance for improved
efficiency of disk access). So there's no percentage in maintaining
support for the old way, and getting rid of it will allow simplification
of code and data structures in the planner.
For all index types? Even lossy ones?
Chris
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
I am about to rip out the code that supports multiple indexscans for OR
conditions inside a single IndexScan plan node. As best I can tell,
the new-style bitmap-OR code is as fast or faster than the old way
even in fully cached test cases (ie, with no allowance for improved
efficiency of disk access). So there's no percentage in maintaining
support for the old way, and getting rid of it will allow simplification
of code and data structures in the planner.
For all index types? Even lossy ones?
Can't see that a lossy index would make any difference ...
regards, tom lane