Re: review: More frame options in window functions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: review: More frame options in window functions
Date: 2010-02-11 20:33:25
Message-ID: 603c8f071002111233n4739e1e0o2c9eaf8278832176@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 11, 2010 at 3:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
>> On Tue, Feb 09, 2010 at 12:37:32PM +0900, Hitoshi Harada wrote:
>>> Now that specialized hard-coding "+"/"-" in source seems unacceptable,
>>> I would like to hear how to handle this. Is there any better than
>>> introducing new mechanism such like opclass?
>
>> I imagine it would be easiest to add these operators to the existing
>> opclass infrastructure. Although it didn't start that way, the opclass
>> structure is being more and more used to declare the semantics of a
>> type. Btree operator classes are for *ordered* types, which seems to be
>> the only case you can expect to work here.
>
>> Currently the btree operator classes have only one support function, so
>> it would seem than the easiest approach would be to declare two new
>> support functions for add() and subtract().
>
> Yeah, that was pretty much the same line of thought I had.  The main
> disadvantage seems to be two more catalog lookups per index to fill in
> support function entries that won't ever be used (at least not by the
> index machinery).  However, I think we cache that stuff already inside
> relcache.c, so it might be insignificant.
>
> The real question is whether it's time to bite the bullet and stop
> overloading the opclass infrastructure for semantics-declaration
> purposes.  Are there any other foreseeable cases where we are going
> to need to add operator knowledge of this sort?

knngist wants to jimmy with the opclass semantics too, though the need
there is a little different. The issue is that an amcanorder AM is
good for optimizing ORDER BY <indexed-column-name>, but that's not
what GIST indices can do: they can optimize ORDER BY
<indexed-column-name> <op> <constant>, for suitable values of op.
Teodor and Oleg handled this by adding a new flag to the AM
(amcanorderbyop) and adding the operators to the opclass. But, unlike
the comparison operators, these operators don't necessarily return a
boolean: in fact they probably don't.

It would be nice to come up with a general solution to this problem.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-02-11 20:52:53 Re: review: More frame options in window functions
Previous Message Tom Lane 2010-02-11 20:32:32 Re: Re: [COMMITTERS] pgsql: Remove old-style VACUUM FULL (which was known for a little while