| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Yeb Havinga <yebhavinga(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: extended operator classes vs. type interfaces |
| Date: | 2010-04-10 19:04:27 |
| Message-ID: | v2w603c8f071004101204r38d1f9c4me478c75533f48343@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Apr 10, 2010 at 2:30 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> 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.
Yeah... I agree.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martijn van Oosterhout | 2010-04-10 20:02:15 | Re: pg_ctl stop -m immediate on the primary server inflates sequences |
| Previous Message | Robert Haas | 2010-04-10 19:02:17 | Re: extended operator classes vs. type interfaces |