Re: Proposal for Merge Join for Non '=' Operators

From: Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>
To: Dilip kumar <dilip(dot)kumar(at)huawei(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal for Merge Join for Non '=' Operators
Date: 2014-04-09 08:01:07
Message-ID: CAP-rdTb-THcvqqBhcO3rZbyjzhRBaSCMgNcZwT=z4xq25HmGRQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2014-04-09 Dilip kumar <dilip(dot)kumar(at)huawei(dot)com>:

> I would like to propose a New merge join algorithm for optimizing non ‘=’
> operators. (‘<’, ‘<=’, ‘>’, ‘>=’)

Do you have a real-world example use case of such joins, to offset the
extra planner time that will likely have to be paid (even for queries
for which the functionality ends up not being used)?

I guess there might be queries that join on “values that are not too
far apart” or something, but as those cases (there typically not being
a lot of “inner” rows that join with each “outer” row) are probably
executed efficiently using a nested loop + index scan, I don’t see the
point (yet). Are you aiming for the case where the inner relation is
difficult to compute and cannot be accessed using an index scan?

> selecting this new cost calculation can be implemented in planner

Hmm. Of course, the difficult part will be adding support for this in
the planner, but you don’t seem to have any plans for implementing
that?

Nicolas

--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2014-04-09 08:05:06 Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Previous Message Peter Geoghegan 2014-04-09 07:40:45 Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)