2014-04-09 Dilip kumar <dilip.kumar@huawei.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?