From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, 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-07-30 23:00:35 |
Message-ID: | 33B858BA-932E-4851-B2D7-589130F19ED1@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 27 Jul 2018, at 21:12, Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru> wrote:
> Thanks for the update.
Thank you for reviewing and hacking!
> On 07/25/2018 01:37 AM, Daniel Gustafsson wrote:
>>
>>> Hmm, this is missing the eqop fields of SortGroupClause. I haven't
>>> tested yet but does the similar degradation happen if two
>>> SortGroupCaluses have different eqop and the same other values?
>> I wasn’t able to construct a case showing this, but I also think you’re right.
>> Do you have an idea of a query that can trigger a regression? The attached
>> patch adds a stab at this, but I’m not sure if it’s the right approach.
>
> To trigger that, in your test example you could order by empno::int8 for one window, and by empno::int2 for another. But don't I think you have to compare eqop here, because if eqop differs, sortop will differ too. I removed the comparison from the patch.
Right, that makes sense.
> I also clarified (I hope) the comments, and did the optimization I mentioned earlier: using array instead of list for active clauses. Please see the attached v6.
Thanks, looks good.
> Otherwise I think the patch is good.
Cool, thanks for reviewing!
cheers ./daniel
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-07-30 23:25:54 | Re: FailedAssertion on partprune |
Previous Message | Alvaro Herrera | 2018-07-30 22:54:46 | Re: negative bitmapset member not allowed Error with partition pruning |