Re: Some notes about redesigning planner data structures

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(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.