From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Yeb Havinga <yebhavinga(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: extended operator classes vs. type interfaces |
Date: | 2010-04-10 18:30:25 |
Message-ID: | 1270924225.5250.14.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 2010-04-10 at 20:25 +0200, Yeb Havinga wrote:
> 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.
Interesting, I would have to make sure that didn't happen. Most likely
there would be a new property like "RANGEMERGES", it wouldn't reuse the
existing MERGES property.
> Sorry for the spam on the list.
Not at all, it's an interesting point.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-04-10 19:02:17 | Re: extended operator classes vs. type interfaces |
Previous Message | Yeb Havinga | 2010-04-10 18:25:30 | Re: extended operator classes vs. type interfaces |