| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Andreas Seltenreich <seltenreich(at)gmx(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Tomas Vondra <tomas(dot)vondra(at)postgresql(dot)org> |
| Subject: | Re: [sqlsmith] Crash in mcv_get_match_bitmap |
| Date: | 2019-07-10 22:48:16 |
| Message-ID: | 19586.1562798896@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-07-10 22:50:17 | Re: Refactoring syslogger piping to simplify adding new log destinations |
| Previous Message | Alvaro Herrera | 2019-07-10 22:41:48 | Re: Refactoring syslogger piping to simplify adding new log destinations |