I have used your notes below to rewrite the Window function SQL manual
section. As you said, it was very hard to read. I now understand it
better, having restructured it, and I hope others do too.
After waiting 30 minutes for our developer doc build to refresh, I am
giving up and posting my own
Florian Pflug writes:
> In addition, I think we should reword the explanation in 4.2.8 (The SQL
> Language
> / SQL Syntax / Value Expressions / Window Functions). Instead of that rather
> long (and IMHO hard to read) paragraph about possible frame clauses and their
> behaviour in the presence or
On Oct17, 2011, at 01:09 , Tom Lane wrote:
> Florian Pflug writes:
>> ... reading those parts again, I realize the it says "When ORDER BY is
>> omitted
>> the *default* frame consists ... ", and that the second quote is followed
>> by a footnote which says
>
>> There are options to define the w
2011/10/17 Greg Stark :
> On Fri, Oct 14, 2011 at 9:32 PM, Tom Lane wrote:
>> We could hack around this by adding more columns to the result so that
>> an index-only scan doesn't work. But I wonder whether it wouldn't be
>> smarter to add ORDER BY clauses to the window function calls. I've been
2011/10/17 Tom Lane :
> Hitoshi Harada writes:
>> 2011/10/15 Tom Lane :
>>> I can't recall whether there was some good reason for underspecifying
>>> these test queries. It looks like all the problematic ones were added in
>>> commit ec4be2ee6827b6bd85e0813c7a8993cfbb0e6fa7 "Extend the set of fra
Florian Pflug writes:
> ... reading those parts again, I realize the it says "When ORDER BY is omitted
> the *default* frame consists ... ", and that the second quote is followed
> by a footnote which says
> There are options to define the window frame in other ways, but this
> tutorial
> do
On Oct17, 2011, at 00:14 , Tom Lane wrote:
> Florian Pflug writes:
>> But some frame clauses (row 1 preceding, for example) have an effect despite
>> there being no ORDER BY, like here:
>
> Yeah, why did you expect differently? Without ORDER BY, all rows are
> peers in the frame ordering, so the
Florian Pflug writes:
> But some frame clauses (row 1 preceding, for example) have an effect despite
> there being no ORDER BY, like here:
Yeah, why did you expect differently? Without ORDER BY, all rows are
peers in the frame ordering, so there's no way for a RANGE spec to
select less than the
Hitoshi Harada writes:
> 2011/10/15 Tom Lane :
>> I can't recall whether there was some good reason for underspecifying
>> these test queries. It looks like all the problematic ones were added in
>> commit ec4be2ee6827b6bd85e0813c7a8993cfbb0e6fa7 "Extend the set of frame
>> options supported for
On Oct16, 2011, at 20:04 , Greg Stark wrote:
> On Fri, Oct 14, 2011 at 9:32 PM, Tom Lane wrote:
>> We could hack around this by adding more columns to the result so that
>> an index-only scan doesn't work. But I wonder whether it wouldn't be
>> smarter to add ORDER BY clauses to the window functi
On Fri, Oct 14, 2011 at 9:32 PM, Tom Lane wrote:
> We could hack around this by adding more columns to the result so that
> an index-only scan doesn't work. But I wonder whether it wouldn't be
> smarter to add ORDER BY clauses to the window function calls. I've been
> known to argue against addi
2011/10/15 Tom Lane :
> I can't recall whether there was some good reason for underspecifying
> these test queries. It looks like all the problematic ones were added in
> commit ec4be2ee6827b6bd85e0813c7a8993cfbb0e6fa7 "Extend the set of frame
> options supported for window functions", which means
So I'm testing a patch to make the planner use measured all-visible-page
counts for index-only scans. I was expecting to possibly see some plan
changes in the regression tests, but this diff scared me:
***
*** 906,921
FROM tenk1 WHERE unique1 < 10;
sum | unique1
-+---
13 matches
Mail list logo
