Re: Whether to back-patch fix for aggregate transtype width estimates - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Whether to back-patch fix for aggregate transtype width estimates
Date
Msg-id CA+TgmoZoKf69qkHX+ORd_pPd-tMjC-fe0Yde3rEX=ksU2FrByg@mail.gmail.com
Whole thread Raw
In response to Whether to back-patch fix for aggregate transtype width estimates  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Whether to back-patch fix for aggregate transtype width estimates  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jun 17, 2016 at 10:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> While fixing the recent unpleasantness over parallel polymorphic
> aggregates, I discovered that count_agg_clauses_walker's consideration
> of an aggregate argument's typmod in estimating transition space
> consumption has been broken since commit 34d26872e (which changed
> Aggref.args from a simple expression list to a list of TargetEntry).
> It had been looking at "exprTypmod((Node *) linitial(aggref->args))",
> and nobody taught it that there was now a TargetEntry in the way that
> it needed to look through to get a correct answer.
>
> Ordinarily I'd just summarily back-patch a fix, but that commit shipped
> in 9.0, which means it's been broken a long time.  I'm worried that
> back-patching a change might be more likely to destabilize plan choices
> than to do anything anybody's happy about.
>
> Thoughts?

I suspect the consequences here aren't too bad, or someone would have
noticed by now.  So I would be tempted to leave it alone in
back-branches.  But I might change my mind if it's actually awful...

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: 10.0
Next
From: Tatsuo Ishii
Date:
Subject: Questionabl description in datatype.sgml