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
------
REL9_1_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/5d7d12de56be2c746bfc30214d3300644e8dc0f3
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(-)