Re: Rethinking representation of sort/hash semantics in queries and plans

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> If you look closely at what we're doing with sort operators
> (get_ordering_op_properties pretty much encapsulates this), it turns out
> that a sort operator is shorthand for three pieces of information:
>
> 1. btree opfamily OID
> 2. specific input datatype for the opfamily
> 3. ascending or descending direction
>
> So to fix these problems we'd need to replace sort operator OIDs in
> SortGroupClause and plan nodes with those three items. Obviously, this
> would be slightly bulkier, but the extra cost added to copying parse and
> plan trees should be tiny compared to the avoided syscache lookups.
>
> A possible compromise is to avoid storing the specific input datatype.

My understanding is that opfamily+datatype gives an opclass. What about
storing the opclass OID there?

Other than that, cleaning up the current situation by having as good an
view of the bigger picture as what you have now sounds great.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support