On Sat, 13 Jun 2020 at 19:52, David Rowley <dgrowleyml@xxxxxxxxx> wrote: > > On Sat, 13 Jun 2020 at 16:07, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > > > > David Rowley <dgrowleyml@xxxxxxxxx> 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
