On Fri, Oct 21, 2016 at 11:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Oct 21, 2016 at 10:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> dromedary seems to have found one, or at least an unstable test result.
>
>> OK, looking at that now. Thanks.
>
> Looking at further failures, it looks like 32-bit machines in general
> get that result. Might be just a cost estimation difference.
>
> Also, some of the windows machines are folding "sqrt(2)" to a different
> constant than is hard-wired into the expected-result file. That's
> slightly annoying because it calls into question whether we can ship
> floating-point computations to the far end at all :-(.
IMHO, not shipping floating-point computations for that reason would
be more annoying than helpful. To really guarantee that the remote
and identical results are identical, you'd need far more
infrastructure than we have - you'd have to make sure the operating
system collations matched, for example. And we're already assuming
(without any proof) that the default collations match and, for that
matter, that the datatypes match. If you're pushing down to
PostgreSQL on the other end, you at least have a hope that the other
side might be sufficiently identical to the local side that the
results will be the same, but if somebody implements these pushdowns
for Oracle or SQL server, you almost might as well give up and go
home. Even for PostgreSQL, getting the same results in every possible
corner case requires a certain degree of optimism.
For my money, the way to handle that is to add more control over
pushdown rather than automatically disabling it in certain cases. For
example, we could have GUCs that disable all pushdown or certain types
of pushdown - e.g. you could specify that you don't trust the remote
side to sort data properly, or that you don't like it's floating-point
implementation. I'm not sure what controls are most useful here, but
I'd be willing to bet you a nice glass of white wine that many people
will be happier with a system that they can control than they will be
with one that just disables the optimization in every case where it
might hypothetically not work out. It's not clear that we can even
reasonably foresee all such cases.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
