Re: KNNGIST next step: adjusting indexAM API
От | Robert Haas |
---|---|
Тема | Re: KNNGIST next step: adjusting indexAM API |
Дата | |
Msg-id | AANLkTimYV9aZ1=c7xdhtWbpvWLOmvhKcm4+naX1q6rq9@mail.gmail.com обсуждение исходный текст |
Ответ на | KNNGIST next step: adjusting indexAM API (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Nov 30, 2010 at 2:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > In the current KNNGIST patch, the indexable ORDER BY clauses are > transmitted to the executor by cramming them in with the index qual > conditions (the IndexScan plan node's indexqual list), from whence > they become part of the ScanKey array passed to the index AM. > Robert complained that this was an ingenious way to minimize the > number of lines touched by the patch but utterly ugly from any other > standpoint, and I quite agree. An ORDER BY clause is a completely > different thing from a WHERE qual, so mixing them together doesn't > seem like a good idea. > > However, if we hold to that principle then we need to modify the indexAM > API to pass the ordering operators separately. This is no big deal as > far as the built-in AMs are concerned, particularly because 3 of the 4 > need only assert that the additional list is empty. The only reason it > would be a problem is if there were third-party index AMs that would be > affected to a larger degree; but I don't know of any. Does anyone have > an objection to that? None here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: