On Wed, Dec 31, 2014 at 9:00 AM, David Rowley <dgrowleyml@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