Review: listagg aggregate
in [PgSql]
|
From: Tom Lane on 28 Jan 2010 12:20 Hitoshi Harada <umi.tanuki(a)gmail.com> writes: > What about get_fn_expr_arg_stable() to check if the argument is stable > during aggregate? Seems quite expensive (possible catalog lookups) and there still isn't any strong argument why we should bother. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 28 Jan 2010 12:24 Pavel Stehule <pavel.stehule(a)gmail.com> writes: > with get_fn_expr_arg_stable() we are able to fix second parameter > without some performance issues. No, that will create its own performance issues --- get_fn_expr_arg_stable isn't especially cheap. If there were a really strong reason why we had to do it, then I'd agree, but frankly the argument for disallowing a variable delimiter is too thin. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Marko Tiikkaja on 28 Jan 2010 12:29 On 2010-01-28 19:17, Pavel Stehule wrote: > 2010/1/28 Hitoshi Harada <umi.tanuki(a)gmail.com>: >> What about get_fn_expr_arg_stable() to check if the argument is stable >> during aggregate? > > I newer know so this function exists. Now we can > > a) check and allow only stable params > b) when second parameter is stable, then store it and use it as constant. > > I prefer a) Someone might have a perfectly good use case for using different delimiters. I don't think it's a good idea to be artificially limiting what you can and can't do. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "David E. Wheeler" on 28 Jan 2010 12:30 On Jan 28, 2010, at 9:29 AM, Marko Tiikkaja wrote: > Someone might have a perfectly good use case for using different > delimiters. I don't think it's a good idea to be artificially limiting > what you can and can't do. +1 David -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Greg Stark on 28 Jan 2010 13:57
One situation where this could actually matter in the long term is if we want to have an optimization for aggregate functions whose state variables can be combined. this could be important if we ever want to do parallel processing someday. So we could have, for example two subjobs build two sublists and then combiner the two lists later. in that case the separator might not be the one the user expected - our put another way the one the user expected might not be available when we need it. We could say this isn't a problem because not all aggregate functions will be amenable to such an optimization and perhaps this will just be one of them. Alternately we could just have faith that a solution will be found - it doesn't seem like it should be an insoluble problem to me. greg On 28 Jan 2010 15:57, "Tom Lane" <tgl(a)sss.pgh.pa.us> wrote: Robert Haas <robertmhaas(a)gmail.com> writes: > On Thu, Jan 28, 2010 at 9:01 AM, Pavel Stehule <pavel.... Yeah. The real issue here is that in some cases you'd like to have non-aggregated parameters to an aggregate, but SQL has no notation to express that. I think Pavel's underlying complaint is that if the delimiter argument isn't constant, then we're exposing an implementation dependency in terms of just which values get separated by which delimiters. The most practical implementation seems to be that the first-call delimiter isn't actually used at all, and on subsequent calls the delimiter *precedes* the associated value, which is a bit surprising given the order in which one writes them. Not sure if this is worth documenting though. Those two or three people who actually try it will figure it out soon enough. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subs... |