Re: [HACKERS] Speed of user-defined aggregates using array_append as transfn

2016-10-29 Thread Tom Lane
I wrote: > I'm still worried about chewing up a kilobyte-at-least for each transition > value, but maybe that's something we could leave to fix later. Another > idea is that we could teach the planner to know about that in its hash > table size estimates. Here's a complete proposed patch for

Re: [HACKERS] Speed of user-defined aggregates using array_append as transfn

2016-10-28 Thread Tom Lane
I wrote: > 3. We could try to fix it mostly from array_append's side, by teaching it > to return the expanded array in the aggregation context when it's being > called as an aggregate function, and making some > hopefully-not-performance-killing tweaks to nodeAgg to play along with > that. This

Re: [HACKERS] Speed of user-defined aggregates using array_append as transfn

2016-10-28 Thread Andrew Dunstan
On 10/28/2016 03:14 PM, Tom Lane wrote: Andrew Dunstan writes: My initial admittedly ugly thought was why not have a second append function that doesn't use expanded arrays? That won't get us out of the O(N^2) behavior. Also I don't see what's better about it than my

Re: [HACKERS] Speed of user-defined aggregates using array_append as transfn

2016-10-28 Thread Tom Lane
Andrew Dunstan writes: > My initial admittedly ugly thought was why not have a second append > function that doesn't use expanded arrays? That won't get us out of the O(N^2) behavior. Also I don't see what's better about it than my suggestion of making array_append itself

Re: [HACKERS] Speed of user-defined aggregates using array_append as transfn

2016-10-28 Thread Andrew Dunstan
On 10/28/2016 02:04 PM, Tom Lane wrote: Comments, better ideas? My initial admittedly ugly thought was why not have a second append function that doesn't use expanded arrays? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)