Andres Freund <and...@anarazel.de> writes:
> Termite is also failing due to differing row orders from the rest of the
> animals. I'd intentionally left those undefined, because I wanted some
> queries without an ORDER BY. Haven't decided what the best fix is yet.
Looks to me like all the bigendian critters are unhappy with that.
The previous plan (trying it on 9.6) was
GroupAggregate (cost=20.68..22.77 rows=400 width=52)
Group Key: dataa, (unnest('{1,1,3}'::integer[]))
-> Sort (cost=20.68..20.69 rows=4 width=40)
Sort Key: dataa, (unnest('{1,1,3}'::integer[]))
-> Seq Scan on few (cost=0.00..20.64 rows=4 width=40)
Filter: (id = 1)
and now we get
HashAggregate (cost=27.66..27.71 rows=4 width=52)
Group Key: dataa, unnest('{1,1,3}'::integer[])
-> ProjectSet (cost=0.00..22.66 rows=400 width=40)
-> Seq Scan on few (cost=0.00..20.62 rows=4 width=36)
Filter: (id = 1)
This is a good thing: it's coming up with a saner rowcount estimate,
ie it realizes that the sort or hash is going to see a number of rows
inflated by the SRF, and that's prompting it to go with a hashagg not
a sortagg. But then you get platform-dependent output order from
the hashagg.
If you don't want an ORDER BY, maybe turn off enable_hashagg for
these queries? But you'll get the same plan either way.
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
