aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist
diff options
context:
space:
mode:
authorTomas Vondra <tomas.vondra@postgresql.org>2019-11-28 22:20:28 +0100
committerTomas Vondra <tomas.vondra@postgresql.org>2019-11-28 22:26:25 +0100
commitef3fed2ce4a3018a992ef913a3333bb682b702ae (patch)
tree449a28cf1ebb9f324df6f06475dbf2ed44ecd551 /src/backend/access/gist
parentbf3cef24a31966686dfaae3085ce7c545c0019a4 (diff)
downloadpostgresql-ef3fed2ce4a3018a992ef913a3333bb682b702ae.tar.gz
postgresql-ef3fed2ce4a3018a992ef913a3333bb682b702ae.zip
Fix choose_best_statistics to check clauses individually
When picking the best extended statistics object for a list of clauses, it's not enough to look at attnums extracted from the clause list as a whole. Consider for example this query with OR clauses: SELECT * FROM t WHERE (t.a = 1) OR (t.b = 1) OR (t.c = 1) with a statistics defined on columns (a,b). Relying on attnums extracted from the whole OR clause, we'd consider the statistics usable. That does not work, as we see the conditions as a single OR-clause, referencing an attribute not covered by the statistic, leading to empty list of clauses to be estimated using the statistics and an assert failure. This changes choose_best_statistics to check which clauses are actually covered, and only using attributes from the fully covered ones. For the previous example this means the statistics object will not be considered as compatible with the OR-clause. Backpatch to 12, where MCVs were introduced. The issue does not affect older versions because functional dependencies don't handle OR clauses. Author: Tomas Vondra Reviewed-by: Dean Rasheed Reported-By: Manuel Rigger Discussion: https://postgr.es/m/CA+u7OA7H5rcE2=8f263w4NZD6ipO_XOrYB816nuLXbmSTH9pQQ@mail.gmail.com Backpatch-through: 12
Diffstat (limited to 'src/backend/access/gist')
0 files changed, 0 insertions, 0 deletions