On Wed, Dec 31, 2014 at 9:00 AM, David Rowley <dgrowle...@gmail.com> wrote: > Yeah, that's what I was talking about. > I'm just looking at the code which uses this size estimate in > choose_hashed_grouping(). I'd be a bit worried giving the difference between > 48 and 128 that we'd under estimate the hash size too much and end up going > to disk during hashagg.
That's an issue, but the problem is that... > I think the patch should be modified so that it uses 128 bytes for the size > estimate on machines that don't support int128, but I'm not quite sure at > this stage if that causes issues for replication, if 1 machine had support > and one didn't, would it matter if the pg_aggregate row on the replica was > 48 bytes instead of 128? Is this worth worrying about? ...if we do this, then yes, there is an incompatibility between binaries compiled with this option and binaries compiled without it. They generate different system catalog contents after initdb and we shouldn't use one set of binaries with an initdb done the other way. That seems like serious overkill, especially since this could not inconceivably flip between one recompile and the next if the administrator has run 'yum update' in the meantime. So I'd argue for picking one estimate and using it across the board, and living with the fact that it's sometimes going to be wrong. Such is the lot in life of an estimate. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
