Re: Implement predicate propagation for non-equivalence clauses

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Richard Guo <riguo(at)pivotal(dot)io>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Implement predicate propagation for non-equivalence clauses
Date: 2018-09-05 06:56:40
Message-ID: 29649.1536130600@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Richard Guo <riguo(at)pivotal(dot)io> writes:
> In this patch, we are trying to do the similar deduction, from
> non-equivalence
> clauses, that is, A=B AND f(A) implies A=B AND f(A) and f(B), under some
> restrictions on f.

Uh, *what* restrictions on f()? In general the above equivalence
does not hold, at least not for any data type more complicated than
integers; and we do not have any semantic model for deciding
which functions it would be correct for.

One simple example to show what I'm talking about is that float8 zero
and minus zero are equal according to float8eq (assuming IEEE float
arithmetic); but they aren't equivalent for any function f() that is
sensitive to the sign or the text representation of the value.
The numeric data type likewise has values that are "equal" without
being identical for all purposes, eg 0.0 vs 0.000. Or consider
citext.

The existing planner deduction rules for equivalence classes are
carefully designed to ensure that we only generate derived clauses
using operators from the same operator class or family, so that
it's on the opclass author to ensure that the operators have consistent
semantics. I don't think we can extrapolate from that to any random
function that accepts the datatype.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jimmy Yih 2018-09-05 07:14:41 Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace
Previous Message Heikki Linnakangas 2018-09-05 06:55:33 Re: Implement predicate propagation for non-equivalence clauses