Robert Haas wrote:
On Sat, Apr 10, 2010 at 12:05 PM, Yeb Havinga <yebhavi...@gmail.com> wrote:
Jeff Davis wrote:
To give some context, I started a thread a while ago:
http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php
Interesting, a join type for overlaps, which makes me think a bit of the
staircase join for pre-post coordinates. However, does a join operator type
need certain kinds of properties of the operator involved, e.g. being
commutative, transitive etc? Else the join reordering fails. The latter
fails for the overlap operator.
I don't think I follow this. As far as I know, the join order
constraints don't depend on the choice of operator.
I was thinking of a case for instance for ranges a,b,c in relations
A,B,C respectively, where a && b and b && c, but not a && c. Would the
planner consider a join path of table A and C first, then that result
with B. After looking in doxygen, it looks like having && defined
without MERGES is what prevents this unwanted behaviour, since that
prevents a,b and c to become members of the same equivalence class.
Sorry for the spam on the list.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
