Re: Rethinking representation of sort/hash semantics in queries and plans - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Rethinking representation of sort/hash semantics in queries and plans
Date
Msg-id 21713.1290979219@sss.pgh.pa.us
Whole thread Raw
In response to Re: Rethinking representation of sort/hash semantics in queries and plans  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> 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.

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

Then you'd just need to look up the opfamily again.  Opclasses are too
small a division to be useful.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: profiling connection overhead
Next
From: Robert Haas
Date:
Subject: Re: [GENERAL] column-level update privs + lock table