Fix gincostestimate to handle ScalarArrayOpExpr reasonably.
The original coding of this function overlooked the possibility that
it could be passed anything except simple OpExpr indexquals. But
ScalarArrayOpExpr is possible too, and the code would probably crash
(and surely give ridiculous answers) in such a case. Add logic to try
to estimate sanely for such cases.
In passing, fix the treatment of inner-indexscan cost estimation: it was
failing to scale up properly for multiple iterations of a nestloop.
(I think somebody might've thought that index_pages_fetched() is linear,
but of course it's not.)
Report, diagnosis, and preliminary patch by Marti Raudsepp; I refactored
it a bit and fixed the cost estimation.
Back-patch into 9.1 where the bogus code was introduced.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/1db5af279441b9ee215b54de424c2af92eeb1ef8
Modified Files
--------------
src/backend/utils/adt/selfuncs.c | 496 +++++++++++++++++++++++----------
src/test/regress/expected/tsearch.out | 12 +
src/test/regress/sql/tsearch.sql | 2 +
3 files changed, 366 insertions(+), 144 deletions(-)
