On Fri, Oct 21, 2016 at 8:50 PM, 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.
How do I or Jeevan get to look at those results?
>
> 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 :-(.
>
There are two things where the floating point push-down can go wrong:
a. the floating point calculation on the foreign server itself is
different from the local server, b. while converting the binary
floating point representation into text, the actual number gets
truncated because of limit on the number of digits in the text
representation. The later can be avoided by using binary data transfer
mode for floating point number. Is that something worth considering?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
