Re: Query Discrepancy in Postgres HLL Test

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Ayush Vatsa <ayushvatsa1810(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Query Discrepancy in Postgres HLL Test
Date: 2024-05-01 19:07:57
Message-ID: CA+TgmoaEJkA_sBJBgFFq3fp7SdD0sYQf+zkZfRyy6gT1OscbhA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 1, 2024 at 1:10 PM Ayush Vatsa <ayushvatsa1810(at)gmail(dot)com> wrote:
> 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" regress test. This particular test data file 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 ........').

PostgreSQL has no function called hll_add or hll_hashval, and no
regression test file called cumulative_add_sparse_edge.sql. A quick
Google search suggests that these things are part of citusdata's fork
of PostgreSQL, so you might want to contact them.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2024-05-01 19:18:41 Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing
Previous Message Thomas Spear 2024-05-01 18:56:26 Re: TLS certificate alternate trust paths issue in libpq - certificate chain validation failing