GEOMETRYCOLLECTION(POINT(4.88394 52.3752), LINESTRING(4.889187 52.373184, 4.885057 52.370159, 4.901618 52.369219, 4.912350 52.374081, 4.914722 52.371667), POLYGON((4.8835 52.3750, 4.8844 52.3750, 4.8844 52.3754, 4.8835 52.3754, 4.8835 52.3750)), MULTIPOLYGON(((4.889187 52.373184, 4.885057 52.370159, 4.901618 52.369219, 4.914722 52.371667, 4.912350 52.374081, 4.889187 52.373184)), ((4.8835 52.3750, 4.8844 52.3750, 4.8844 52.3754, 4.8835 52.3754, 4.8835 52.3750))))
{
"values": [1, 2, 3, 4, 5, 5, 5,6, ,1324234,3214,324,45,4325,5432,52435,2435432,54325,43254325,4325,234],
"counts": [1, 2, 3, 4, 5this could be mbs of numbers, 5, 5,6, ,1324234,3214,324,45,4325,5432,52435,2435432,54325,43254325,4325,234]
}
Description
The
TO_STRINGfunction converts values into utf-8 strings. Usually these strings are quite short1,3.14159246,lemon,POINT (2.2945 48.8584). But sometimes the strings the strings can be big:or
We have great tracking against super long
Blocks and the like, but while the values are in flight the code currently doesn't track the usage.We should limit the size of the results for all of the "big" types:
histogramHistogram field data type #139457geo_shape/cartesian_shapeexponential_histogramES|QL: Guard exponential_histogram TO_STRING against too large inputs #140718tdigest