Fix logical errors in tsquery selectivity estimation for prefix queries.
I made multiple errors in commit 97532f7c29468010b87e40a04f8daa3eb097f654,
stemming mostly from failure to think about the available frequency data
as being element frequencies not value frequencies (so that occurrences of
different elements are not mutually exclusive). This led to sillinesses
such as estimating that "word" would match more rows than "word:*".
The choice to clamp to a minimum estimate of DEFAULT_TS_MATCH_SEL also
seems pretty ill-considered in hindsight, as it would frequently result in
an estimate much larger than the available data suggests. We do need some
sort of clamp, since a pattern not matching any of the MCELEMs probably
still needs a selectivity estimate of more than zero. I chose instead to
clamp to at least what a non-MCELEM word would be estimated as, preserving
the property that "word:*" doesn't get an estimate less than plain "word",
whether or not the word appears in MCELEM.
Per investigation of a gripe from Bill Martin, though I suspect that his
example case actually isn't even reaching the erroneous code.
Back-patch to 9.1 where this code was introduced.
Branch
------
REL9_2_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/31f1b2090fc08f923e56e2421086ef60d6b89c1e
Modified Files
--------------
src/backend/tsearch/ts_selfuncs.c | 44 +++++++++++++++++++++++-------------
1 files changed, 28 insertions(+), 16 deletions(-)
