From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Rémi Cura <remi(dot)cura(at)gmail(dot)com> |
Cc: | Hubert Lubaczewski <depesz(at)depesz(dot)com>, Robert James <srobertjames(at)gmail(dot)com>, Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Count of records in a row |
Date: | 2013-10-22 14:27:22 |
Message-ID: | CAHyXU0w_ftCU=hDWpF1N1oFDwVpB4U3LrAcOB0-1XiDV8NNVXw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Oct 22, 2013 at 9:09 AM, Rémi Cura <remi(dot)cura(at)gmail(dot)com> wrote:
>
> Thanks for this good example Merlin !
>
> I didn't know you could use variable inside custom aggregates, and this
> allow to solve the problem!
>
> In my own problem I couldn't use aggregates because
> _as it output at most one row, it would have mean a lots of useless
> computation (as in this example I guess, (please correct me if it's not the
> case) :
That is not the case. With the approach above what you 'pay' vs
standard loop is basically one pl/pgsql function call per output row.
(you can do it in straight sql, but when with pl/pgsql to leverage
cached function parsing). What you 'get' is a more general function
because the loop structure is in the query itself as well as the
output structure. This cleanly separates action from the data.
Usually, the mechanics of executing the aggregate are not a huge part
of query execution time. Actually, the worst case is when the
aggregate is trivial but no matter what it's O(n).
I'm not clear what on the issue is with your particular case, since
you didn't post it :-). Maybe post some extra detail?
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Rémi Cura | 2013-10-22 14:43:36 | Re: Count of records in a row |
Previous Message | Rémi Cura | 2013-10-22 14:09:12 | Re: Count of records in a row |