Re: extended operator classes vs. type interfaces
От | Robert Haas |
---|---|
Тема | Re: extended operator classes vs. type interfaces |
Дата | |
Msg-id | m2i603c8f071004101202g7b6711afn8cfa65e76d89b2b9@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: extended operator classes vs. type interfaces (Jeff Davis <pgsql@j-davis.com>) |
Список | pgsql-hackers |
On Fri, Apr 9, 2010 at 5:49 PM, Jeff Davis <pgsql@j-davis.com> wrote: > On Thu, 2010-04-08 at 22:29 -0400, Robert Haas wrote: >> 1. knngist wants to use index scans to speed up queries of the form >> SELECT ... ORDER BY <column> <op> <constant> (as opposed to the >> existing machinery which only knows how to use an index for SELECT ... >> ORDER BY <column>). >> 2. Window functions want to define windows over a range of values >> defined by the underlying data type. To do this, we need to define >> what addition and subtraction mean for a particular data type. >> 3. Jeff Davis is interested in implementing range types. When the >> underlying base type is discrete, e.g. integers, you can say that >> [1,3] = [1,4), but only if you know that 3 and 4 are consecutive (in >> that order). > > To give some context, I started a thread a while ago: > > http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php > > Tom provided some interesting suggestions in that thread, but I'm not > sure they would work for #1 or #2. <rereads thread> The "map && to <<" case is interesting. It doesn't seem like it's really a good candidate for type interfaces, because you you're not really looking for "the" strictly-left-of operator; you're looking for the strictly-left-of operator associated with the overlaps operator actually specified. And ideally there might be an index strategy number available for <<, too, so that you could consider doing an index scan instead of a sort, but not necessarily. ...Robert
В списке pgsql-hackers по дате отправления: