On 28 April 2014 15:01, Robert Haas wrote:
> Interesting. This can pretty obviously produce a big win if things
> break our way. But it'll take some effort do determine whether the
> range of possible values for the join column is narrow enough to make
> the inferred BETWEEN clause selective en
On Tue, Apr 22, 2014 at 11:44 AM, Simon Riggs wrote:
> I was recently nudged to describe an optimisation of merge
> joins/sorts. Rather than decribe that, I've looked at the general
> case:
>
> There are some additional implications we may make when joining
> tables... a particularly interesting o
On 22 April 2014 17:00, Stephen Frost wrote:
> Simon,
>
> This all looks good, and at the risk of being slightly off-topic for
> this thread, I just wanted to mention..
>
> * Simon Riggs (si...@2ndquadrant.com) wrote:
>> Current proposal ends there, but there is a further optimization that
>> allo
Simon,
This all looks good, and at the risk of being slightly off-topic for
this thread, I just wanted to mention..
* Simon Riggs (si...@2ndquadrant.com) wrote:
> Current proposal ends there, but there is a further optimization that
> allows us to remove the join altogether if
> * There is a FK b
I was recently nudged to describe an optimisation of merge
joins/sorts. Rather than decribe that, I've looked at the general
case:
There are some additional implications we may make when joining
tables... a particularly interesting one is that
SELECT *
FROM Fact JOIN Dim on Fact.col = Dim.col
ca
