On Sun, Oct 9, 2016 at 10:10 PM, Sebastian P. Luque <spluque@xxxxxxxxx> wrote: > On Sun, 09 Oct 2016 16:00:21 -0400, > Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > >> "Sebastian P. Luque" <spluque@xxxxxxxxx> writes: >>> Tom Lane <tgl@xxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
