Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused
Date: 2018-09-12 21:31:50
Message-ID: 20458.1536787910@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> So I'm looking to commit this, and here's my comments so far:

I took a quick look over this. I agree with your nitpicks, and have
a couple more:

* Please run it through pgindent. That will, at a minimum, remove some
gratuitous whitespace changes in this patch. I think it'll also expose
some places where you need to change the code layout to prevent pgindent
from making it look ugly. Notably, this:

actives[nActive].uniqueOrder = list_concat_unique(
list_copy(wc->partitionClause), wc->orderClause);

is not per project style for function call layout. Given the other
comment about using list_union, I'd probably lay it out like this:

actives[nActive].uniqueOrder = list_union(wc->partitionClause,
wc->orderClause);

* The initial comment in select_active_windows,

/* First, make a list of the active windows */

is now seriously inadequate as a description of what the subsequent
loop does; it needs to be expanded. I'd also say that it's not
building a list anymore, but an array. Further, there needs to be
an explanation of why what it's doing is correct at all ---
list_union doesn't make many promises about the order of the resulting
list (nor did the phraseology with list_concat_unique), but what we're
doing below certainly requires that order to have something to do with
the window semantics.

* I'm almost thinking that changing to list_union is a bad idea, because
that obscures the fact that we're relying on the relative order of
elements in partitionClause and orderClause to not change; any future
reimplementation of list_union would utterly break this code. I'm also a
bit suspicious as to whether the code is even correct; does it *really*
match what will happen later when we create sort plan nodes? (Maybe it's
fine; I haven't looked.)

* The original comments also made explicit that we were not considering
framing options, and I'm not too happy that that disappeared.

* It'd be better if common_prefix_cmp didn't cast away const.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Arthur Zakirov 2018-09-12 21:39:34 Re: PATCH: Update snowball stemmers
Previous Message Christoph Berg 2018-09-12 21:07:34 Re: [patch] Support LLVM 7