On Sat, 13 Jun 2020 at 19:52, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Sat, 13 Jun 2020 at 16:07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > David Rowley <dgrowleyml@gmail.com> writes:
> > > I wondered if it would be more simple to add some smarts to look a bit
> > > deeper into case statements for selectivity estimation purposes. An
> > > OpExpr like:
> > > CASE c.contype WHEN 'c' THEN 'CHECK' WHEN 'f' THEN 'FOREIGN KEY' WHEN
> > > 'p' THEN 'PRIMARY KEY' WHEN 'u' THEN 'UNIQUE' END = 'CHECK';
> >
> > Hm. Maybe we could reasonably assume that the equality operators used
> > for such constructs are error-and-side-effect-free, thus dodging the
> > semantic problem I mentioned in the other thread?
>
> I'm only really talking about selectivity estimation only for now.
> I'm not really sure why we'd need to ensure that the equality operator
> is error and side effect free. We'd surely only be executing the case
> statement's operator's oprrest function? We'd need to ensure we don't
> invoke any casts that could error out.
Hmm, after a bit of thought I now see what you mean. We'd need to
loop through each WHEN clause to ensure there's a Const and check if
that Const is equal to the Const on the other side of the OpExpr, then
select the first match. That, of course, must perform a comparison,
but, that's not really doing anything additional to what constant
folding code already does, is it?
David
