2010/1/24 Simon Riggs <si...@2ndquadrant.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" exception. > > * 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 www.2ndQuadrant.com > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers