You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Send results of select pg_catalog.gp_acquire_sample_rows query in binary mode.
That allows to avoid overflow for max double.
For example, if run the following prior to this fix:
set extra_float_digits to 0;
create table t (a double precision);
insert into t values (1.7976931348623157e+308);
analyze t;
the following message will be printed:
ERROR: value out of range: overflow
For text mode (default) when analyze for table is performed the
master calls gp_acquire_sample_rows() helper function on each
segment. That eventually calls float8out function on segment to
converts float8 number to a string with snprintf:
snprintf(ascii, MAXDOUBLEWIDTH + 1, "%.*g", ndig, num);
When ndig is 15 the maximum float8 value 1.7976931348623157e+308 is
rounded to "1.79769313486232e+308" that has no representation.
And on master acquire_sample_rows_dispatcher function
process gp_acquire_sample_rows result and eventually float8in
function is called to convert string to float8 with strtold:
val = strtold(num, &endptr);
This is where overflow for "1.79769313486232e+308" happens but works
fine for "1.7976931348623157e+308".
Transferring in binary mode allows to avoid conversion from double to
string on segments and then back to double on master. And this will
much faster than before.
Using CdbDispatchPlan instead of CdbDispatchCommand allows
to receive data in binary mode in MemTuple, and this is much faster than before.
And use tuplestore to store received tuples to avoid use too many memory.
Co-authored-by: zxuejing <[email protected]>
0 commit comments