MIME-Version: 1.0
From: Ayush Vatsa <ayushvatsa1810@gmail.com>
Date: Sun, 28 Apr 2024 18:31:05 +0530
Message-ID: <CACX+KaPCQAZn_+HzNEuw6qEP8Wv+p8wQpkf6dqM4ZGu5E91p-Q@mail.gmail.com>
Subject: Query Discrepancy in Postgres HLL Test
To: pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000007a6b66061727bbb6"
Archived-At: <https://www.postgresql.org/message-id/CACX%2BKaPCQAZn_%2BHzNEuw6qEP8Wv%2Bp8wQpkf6dqM4ZGu5E91p-Q%40mail.gmail.com>
Precedence: bulk

--0000000000007a6b66061727bbb6
Content-Type: text/plain; charset="UTF-8"

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).

Regards
Ayush Vatsa

--0000000000007a6b66061727bbb6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi PostgreSQL Community,<br>I&#39;m currently delving into=
 Postgres HLL (HyperLogLog) functionality and=20
have encountered an unexpected behavior while executing queries from the
 &quot;<a href=3D"https://github.com/citusdata/postgresql-hll/blob/master/s=
ql/cumulative_add_sparse_edge.sql#L28-L36">cumulative_add_sparse_edge.sql</=
a>&quot; regress test. This particular test <a href=3D"https://github.com/c=
itusdata/postgresql-hll/blob/master/sql/data/cumulative_add_sparse_edge.csv=
#L515-L516">data file</a> involves three columns, with the last column=20
representing an HLL (HyperLogLog) value derived from the previous HLL=20
value and the current raw value.<div><br></div><div>Upon manual inspection =
of the query responsible for deriving the last=20
row&#39;s HLL value, I noticed a discrepancy. When executing the query:<br>=
</div><div>&quot;&quot;&quot;</div><div>-- &#39;\x148B481002....&#39; is se=
cond last rows hll value</div><div>SELECT hll_add(&#39;\x148B481002.....=
9;, hll_hashval(2561));<br></div><div>&quot;&quot;&quot;</div><div>instead =
of obtaining the expected value (&#39;&#39;\x148B481002....&#39;&#39;), I=
=20
received a different output which is (&#39;\x138b48000200410061008100a1 ...=
.....&#39;).<br></div><div><br></div><div>My initial assumption is that thi=
s could potentially be attributed to a=20
precision error. However, I&#39;m reaching out to seek clarity on why this=
=20
disparity is occurring and to explore potential strategies for=20
mitigating it (as I want the behaviour to be consistent to regress test fil=
e).<br></div><div><br></div><div>Regards</div><div>Ayush Vatsa</div></div>

--0000000000007a6b66061727bbb6--