Skip site navigation (1) Skip section navigation (2)

Re: Review: listagg aggregate

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: "David E(dot)Wheeler" <david(at)kineticode(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Review: listagg aggregate
Date: 2010-01-24 18:40:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2010/1/24 Simon Riggs <simon(at)2ndquadrant(dot)com>:
> On Fri, 2010-01-22 at 11:14 -0800, David E.Wheeler wrote:
>> No performance issues
> ISTM that this class of function is inherently dangerous performance
> wise.

there is potencial risk, but this risk isn't new. The almost all what
you say is true for array aggregates.

> * It looks incredibly easy to construct enormous lists. We should test
> the explosion limit of this to see how it is handled. Perhaps we need
> some parameter limits to control that, depending upon results.

There are no limit for generating large values - like bytea, xml, or
text. There are not limit for array_accum or array(query). So, I don't
think we need some special mechanism for listagg. If somebody will
generate too large a value, then he will get "out of memory"

> * Optimizer doesn't consider whether the result type of an aggregate get
> bigger as the aggregate processes more rows. If we're adding this
> function we should give some thought in that area also, or at least a
> comment to note that it can and will cause the optimizer problems in
> complex queries.

this is true, but this isn't some new. array_accum working well
without optimizer problems.

> --
>  Simon Riggs 
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:

In response to

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2010-01-24 18:40:41
Subject: Re: Resetting a single statistics counter
Previous:From: Tom LaneDate: 2010-01-24 18:33:27
Subject: Re: Resetting a single statistics counter

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group