Re: [sqlsmith] Crash in mcv_get_match_bitmap
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andreas Seltenreich <seltenreich@gmx.de>, pgsql-hackers@lists.postgresql.org, Tomas Vondra <tomas.vondra@postgresql.org>
Date: 2019-07-11T15:08:22Z
Lists: pgsql-hackers
On Wed, Jul 10, 2019 at 06:48:16PM -0400, Tom Lane wrote: >Oh ... while we're piling on here, it just sunk into me that >mcv_get_match_bitmap is deciding what the semantics of an operator >are by seeing what it's using for a selectivity estimator. >That is just absolutely, completely wrong. For starters, it >means that the whole mechanism fails for any operator that wants >to use a specialized estimator --- hardly an unreasonable thing >to do. For another, it's going to be pretty unreliable for >extensions, because I do not think they're all careful about using >the right estimator --- a lot of 'em probably still haven't adapted >to the introduction of separate <= / >= estimators, for instance. > >The right way to determine operator semantics is to look to see >whether they are in a btree opclass. That's what the rest of the >planner does, and there is no good reason for the mcv code to >do it some other way. > Hmmm, but that will mean we're unable to estimate operators that are not part of a btree opclass. Which is a bit annoying, because that would also affect equalities (and thus functional dependencies), in which case the type may easily have just hash opclass or something. But maybe I just don't understand how the btree opclass detection works and it'd be fine for sensibly defined operators. Can you point me to code doing this elsewhere in the planner? We may need to do something about code in pg10, because functional dependencies this too (although just with F_EQSEL). But maybe we should leave pg10 alone, we got exactly 0 reports about it until now anyway. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Use column collation for extended statistics
- a63378a03ec0 13.0 landed
- 5a8ee9f2dbe0 12.0 landed
-
Rework examine_opclause_expression to use varonleft
- e38a55ba46bb 13.0 landed
- fc4faea17971 12.0 landed
-
Fix handling of NULLs in MCV items and constants
- 1c2acc32dc6c 12.0 landed
- e4deae7396f2 13.0 landed
-
Fix handling of opclauses in extended statistics
- 42276976a143 12.0 landed
- e8b6ae2130e3 13.0 landed
-
Remove unnecessary TYPECACHE_GT_OPR lookup
- 3944e855bc5b 12.0 landed
- a4303a078c66 13.0 landed
-
Simplify bitmap updates in multivariate MCV code
- 79d3a1e52a3c 12.0 landed
- 7d24f6a49076 13.0 landed
-
Make pg_statistic and related code account more honestly for collations.
- 5e09280057a4 12.0 cited