On Sun, Oct 9, 2016 at 10:10 PM, Sebastian P. Luque <spluque@gmail.com> wrote:
> On Sun, 09 Oct 2016 16:00:21 -0400,
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> "Sebastian P. Luque" <spluque@gmail.com> writes:
>>> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> On closer inspection, the error is only in the
>>>> aggregate-used-as-window-function case, not plain aggregation.
>
>>> Yes, I see the same phenomenon. Could someone suggest a workaround
>>> until this is fixed? I'm under the gun to submit output tables and
>>> the only thing I can think of is a crawling slow loop to step through
>>> each window twice: once using the plain aggregation and another
>>> without just get all rows. I highly doubt it will be worthwhile,
>>> given it's going to be about 1000 iterations, and each one would take
>>> about 30-45 min...
>
>> Are you in a position to apply patches? It's a one-line fix:
>> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=dca25c2562199ce1e7e26367613912a8eadbbde8
>
>> Alternatively, the problem doesn't manifest when the aggregate
>> transtype and output type are the same, so you could probably refactor
>> your code to use plain array_agg and apply the finalfunc separately in
>> the SQL query.
>
> Perfect, I'll try the latter option on this one. Thanks so much to both
> of you for your prompt feedback!
Aside: nice use of custom aggregates through window functions. I use
this tactic heavily.
merlin