Re: [HACKERS] Whether to back-patch fix for aggregate transtype width estimates

2016-06-19 Thread Tomas Vondra
On 06/18/2016 06:14 PM, Tom Lane wrote: Robert Haas writes: On Fri, Jun 17, 2016 at 10:41 PM, Tom Lane wrote: 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

Re: [HACKERS] Whether to back-patch fix for aggregate transtype width estimates

2016-06-18 Thread Greg Stark
On Sat, Jun 18, 2016 at 5:14 PM, Tom Lane wrote: > . In 9.x, that's broken and it falls back to > get_typavgwidth's default guess of 32 bytes. If what you've actually > got is, say, varchar(255) and most of the entries actually approach > that length, this could result in a

Re: [HACKERS] Whether to back-patch fix for aggregate transtype width estimates

2016-06-18 Thread Tom Lane
Robert Haas writes: > On Fri, Jun 17, 2016 at 10:41 PM, Tom Lane wrote: >> 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

Re: [HACKERS] Whether to back-patch fix for aggregate transtype width estimates

2016-06-17 Thread Robert Haas
On Fri, Jun 17, 2016 at 10:41 PM, Tom Lane 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

[HACKERS] Whether to back-patch fix for aggregate transtype width estimates

2016-06-17 Thread Tom Lane
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