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
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
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
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
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)