Re: [Proposal] Table partition + join pushdown - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [Proposal] Table partition + join pushdown
Date
Msg-id CAM-w4HPCaWqvdRuVevxAV=qtYx-uVGBKP1NWMP1o=43pTPXpgQ@mail.gmail.com
Whole thread Raw
In response to Re: [Proposal] Table partition + join pushdown  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [Proposal] Table partition + join pushdown  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Jan 18, 2016 at 5:55 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> For
> example, suppose that x and y are numeric columns and P(x) is
> length(x::text) == 3.  Then you could have 1 in one table and 1.0 in
> the table; they join, but P(x) is true for one and false for the
> other.


Fwiw, ages ago there was some talk about having a property on
functions "equality preserving" or something like that. If a function,
or more likely a <function,operator> tuple had this property set then
x op y => f(x) op f(y). This would be most useful for things like
substring or hash functions which would allow partial indexes or
partition exclusion to be more generally useful.

Of course then you really want <f,op1,op2> to indicate that "a op1 b
=> f(a) op2 f(b)" so you can handle things like <substring,lt,lte > so
that "a < b => substring(a,n) <= substring(b,n)" and you need some way
to represent the extra arguments to substring and the whole thing
became too complex and got dropped.

But perhaps even a simpler property that only worked for equality and
single-argument functions would be useful since it would let us mark
hash functions Or perhaps we only need to mark the few functions that
expose properties that don't affect equality since I think there are
actually very few of them.

-- 
greg



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Combining Aggregates
Next
From: Pavel Stehule
Date:
Subject: Re: custom function for converting human readable sizes to bytes