On Fri, Oct 21, 2016 at 8:50 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Oct 21, 2016 at 10:47 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
