On Sun, 09 Oct 2016 16:00:21 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote:
> "Sebastian P. Luque" <splu...@gmail.com> writes: >> Tom Lane <t...@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! -- Seb -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
