Skip site navigation (1) Skip section navigation (2)

Re: review: More frame options in window functions

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-01-19 00:48:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2010/1/19 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> writes:
>> In a RANGE offset mode query, for example:
>> SELECT sum(ten) over (PARTITION BY four ORDER BY four RANGE BETWEEN 2
>> the frame is determined as "from the first row which has <four> value
>> - 2 to the last row which has <four> value - 1" and executor should
>> know <four> value *is* the sort column even if the column is not
>> actually significant. But the planner removes that information.
> Maybe we're just talking past each other.  My point is that the planner
> should record the fact that four is the sort column someplace where the
> executor can find it easily.  AFAICS that doesn't mean it can't be the
> canonicalized form of the sort key.  If a column is dropped out of the
> canonical sort key then it's simply redundant, and hence not relevant to
> determining the range.

Yeah, that's my point, too. The planner has to distinguish "four" from
sort pathkeys and to teach the executor the simple information which
column should be used to determine frame. I was bit wrong because some
of current executor code isn't like it, like using ordNumCols == 0 to
know whether partition equals to frame, though....


Hitoshi Harada

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-01-19 00:49:59
Subject: Re: parallel regression test output
Previous:From: Tom LaneDate: 2010-01-19 00:42:28
Subject: Re: Patch: Remove gcc dependency in definition of inline functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group