Re: knngist - 0.8

On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I'm satisfied to say that only one sort order can be associated with a
>>> particular operator in a particular opclass, which is what would be
>>> implied by using AMOP_SEARCH/AMOP_ORDER as the unique key component.
>
>> Does that imply that KNNGIST would only be able to support one
>> ordering per AMOP_ORDER-operator, or does it imply that each such
>> ordering would require a separate strategy number?  The second might
>> be OK, but the first sounds bad.
>
> It would be the first, because simply assigning another strategy number
> only satisfies one of the unique constraints on pg_amop.  To allow
> arbitrary flexibility here, we would have to include all components of
> the ordering specification in the unique constraint that's presently
> just (amopopr, amopfamily) and is proposed to become
> (amopopr, amopfamily, amoppurpose).  I think that's an undue amount of
> complexity to support something that's most likely physically impossible
> from the index's standpoint anyway.

Or, you'd need to pass these details separately to the AM, which seems
like a more more flexible way of doing it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company