[prev in list] [next in list] [prev in thread] [next in thread]
List: postgresql-general
Subject: Re: Query Discrepancy in Postgres HLL Test
From: Adrian Klaver <adrian.klaver () aklaver ! com>
Date: 2024-04-28 15:07:48
Message-ID: a808a4b3-7f1d-4826-bc44-55565f0a99b9 () aklaver ! com
[Download RAW message or body]
On 4/28/24 06:01, Ayush Vatsa wrote:
> Hi PostgreSQL Community,
> I'm currently delving into Postgres HLL (HyperLogLog) functionality and
> have encountered an unexpected behavior while executing queries from the
> "cumulative_add_sparse_edge.sql
> <https://github.com/citusdata/postgresql-hll/blob/master/sql/cumulative_add_sparse_edge.sql#L28-L36>" \
> regress test. This particular test data file \
> <https://github.com/citusdata/postgresql-hll/blob/master/sql/data/cumulative_add_sparse_edge.csv#L515-L516> \
> involves three columns, with the last column representing an HLL (HyperLogLog) \
> value derived from the previous HLL value and the current raw value.
> Upon manual inspection of the query responsible for deriving the last
> row's HLL value, I noticed a discrepancy. When executing the query:
> """
> -- '\x148B481002....' is second last rows hll value
> SELECT hll_add('\x148B481002.....', hll_hashval(2561));
> """
> instead of obtaining the expected value (''\x148B481002....''), I
> received a different output which is ('\x138b48000200410061008100a1
> ........').
>
> My initial assumption is that this could potentially be attributed to a
> precision error. However, I'm reaching out to seek clarity on why this
> disparity is occurring and to explore potential strategies for
> mitigating it (as I want the behaviour to be consistent to regress test
> file).
I would say your best option is to file an issue here:
https://github.com/citusdata/postgresql-hll/issues
>
> Regards
> Ayush Vatsa
--
Adrian Klaver
adrian.klaver@aklaver.com
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic