I wrote:
> Now, this loss of flexibility doesn't particularly bother me, because
> I know of no existing or contemplated btree-substitute access methods.
> If one did appear on the horizon, there are a couple of ways we could
> fix the problem, the cleanest being to let a non-btree opfamily declare
I wrote:
> (For some extra amusement, trace through where
> build_index_pathkeys' data comes from...)
While I don't propose to implement right away the whole SortGroupClause
and plan tree modification sketched above, I did look into fixing
build_index_pathkeys so that it doesn't uselessly convert
Dimitri Fontaine writes:
> Tom Lane 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 co
Tom Lane 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
On Sat, Nov 27, 2010 at 10:02:33PM -0500, Tom Lane wrote:
> In recent discussions of the plan-tree representation for KNNGIST index
> scans, there seemed to be agreement that it'd be a good idea to explicitly
> represent the expected sort ordering of the output. While thinking about
> how best to
In recent discussions of the plan-tree representation for KNNGIST index
scans, there seemed to be agreement that it'd be a good idea to explicitly
represent the expected sort ordering of the output. While thinking about
how best to do that, it struck me that there's some pretty horrendous
impedanc
