Re: knngist - 0.8
От | Robert Haas |
---|---|
Тема | Re: knngist - 0.8 |
Дата | |
Msg-id | AANLkTi=WhcD3t8iQUd+T3uQnEHbNe5HuyuQo2k=mxU59@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: knngist - 0.8 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: knngist - 0.8
|
Список | pgsql-hackers |
On Tue, Nov 23, 2010 at 11:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: