On 29 April 2014 13:28, Hadi Moshayedi Wrote,
>This looks like a great improvement. Repeating Nicolas's question, do you have
>a real-world example of such joins?
I can think of some scenario where, user need to self-join and find the
comparison with other tuples, For example, list down all th
Hello Dilip,
Query: select count(*) from t1,t2 where t1.b 12000;
>
> Test Result:
> Nest Loop Join with Index Scan : 1653.506 ms
> Sort Merge Join for (seq scan) : 610.257ms
>
>
This looks like a great improvement. Repeating Nicolas's question, d
On 10 April 2014 14:21, I wrote
>
> I shall perform some more test, for that I need to do some more hack in
> the code and I will post them soon..
>
> Test Scenario:
> Create table t1 (a int, b int);
> Create table t2 (a int, b int);
>
> Random record inserted in t1 and t2, as
Dilip kumar writes:
> On 09 April 2014 13:31, Nicolas Barbier Wrote
>> 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 think this will be mor
On 09 April 2014 13:31, Nicolas Barbier Wrote
> 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 “va
2014-04-09 Dilip kumar :
> 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 funct
I would like to propose a New merge join algorithm for optimizing non '='
operators. ('<', '<=', '>', '>=')
- Currently Merge join is only supported for '=' operator. For '<' or
'>' operator it chooses Nest Loop Join, or Nest loop with materialization.
- I think when tuple f