Robert Haas wrote: > On Fri, Mar 24, 2017 at 1:16 PM, Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote: > > Implement multivariate n-distinct coefficients > > dromedary and arapaima have failures like this, which seems likely > related to this commit: > > EXPLAIN > SELECT COUNT(*) FROM ndistinct GROUP BY a, d; > QUERY PLAN > --------------------------------------------------------------------- > ! HashAggregate (cost=225.00..235.00 rows=1000 width=16) > Group Key: a, d > ! -> Seq Scan on ndistinct (cost=0.00..150.00 rows=10000 width=8) > (3 rows)
Yes. What seems to be going on here, is that both arapaima and dromedary are 32 bit machines; all the 64 bit ones are passing (except for prion which showed a real relcache bug, which I already stomped). Now, the difference is that the total cost in those machines for seqscan is 155 instead of 150. Tomas suggests that this happens because MAXALIGN is different, leading to packing tuples differently: the expected cost (on our laptop's 64 bit) is 155, and the cost we get in 32 bit arch is 150 -- so 5 pages of difference. We insert 1000 rows on the table; 4 bytes per tuple would amount to 40 kB, which is exactly 5 pages. I'll push an alternate expected file for this test, which we think is the simplest fix. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
