From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
cc: Andreas Seltenreich <seltenreich@gmx.de>,
        pgsql-hackers@lists.postgresql.org,
        Tomas Vondra <tomas.vondra@postgresql.org>
Subject: Re: [sqlsmith] Crash in mcv_get_match_bitmap
In-reply-to: <20190710215904.ncaqlswrylliisv3@development>
References: <8736jdhbhc.fsf@ansel.ydns.eu> <15097.1562792274@sss.pgh.pa.us>
 <20190710212609.5mrl7hltbozoxpq7@development>
 <17042.1562795124@sss.pgh.pa.us>
 <20190710215904.ncaqlswrylliisv3@development>
Comments: In-reply-to Tomas Vondra <tomas.vondra@2ndquadrant.com>
	message dated "Wed, 10 Jul 2019 23:59:04 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19585.1562798896.1@sss.pgh.pa.us>
Date: Wed, 10 Jul 2019 18:48:16 -0400
Message-ID: <19586.1562798896@sss.pgh.pa.us>
Precedence: bulk

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