2014-04-09 Dilip kumar <dilip.ku...@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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
