On Thu, Jan 11, 2007 at 04:03:55PM -0500, Tom Lane wrote: > I've been looking at improving the planner so that it can handle things > like backwards-order mergejoins, and I'm starting to realize that the > old assumption that mergejoinable operators had only one associated sort > ordering is wired into even more places than I thought. In particular, > the PathKeys data structure (see src/backend/optimizer/README if you > don't know about it) seems to need revisions. As it stands we'd have to > generate a lot of redundant PathKeys.
<snip much mind-blowing stuff> For the parts I understand, I agree. This is something that long-term will allow the planner to make smarter decisions about relations between different types. And if in the future we ever implement COLLATE, I think we're creating the right level of abstraction here. > A possible objection to this is that it ties the planner's handling of > sort ordering even more tightly to btree, but actually I think that's > not a big problem. We could handle opfamilies belonging to multiple > orderable index types as long as they all use btree's strategy numbers. > In any case, with no new orderable index types on the horizon, I'm not > all that worried about this. No problem here, the btree structure is portgresql representation of the concept of "order" so it's logical it gets tied in everywhere. > One of the things I don't like about generate_implied_equalities is that > it has to fail if there's no cross-type equality operator for a > particular datatype combination. Currently we tell people they'd better > make sure that mergejoinable operators come in complete cross-type sets, > but that's not real attractive. This approach can improve the > situation: rather than failing if we can't generate *all* the equality > combinations implied by a particular equivalence set, we need only fail > if we can't generate *any* of the valid combinations for a particular > join. What's more, "failure" need no longer mean elog(ERROR), it just > means we reject that particular join path as invalid. (We can be sure > we will still be able to find some solution to the join problem, since > at least the join path directly implied by the original clauses will > work.) Sounds great... PS. I'm glad you're doing this, because I wouldn't know where to start... Keep up the good work! Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature