Re: Preallocation changes in Postgresql 16

[Riku Iki]

Thank you, I have such a system. I think my task would be to compile PG
from sources(need to learn this), and see how it works with and without
that code block.

On Thu, Apr 25, 2024 at 2:25 PM Thomas Munro  wrote:

> On Fri, Apr 26, 2024 at 4:37 AM Riku Iki  wrote:
> > I am wondering if there were preallocation related changes in PG16, and
> if it is possible to disable preallocation in PostgreSQL 16?
>
> I have no opinion on the btrfs details, but I was wondering if someone
> might show up with a system that doesn't like that change.  Here is a
> magic 8, tuned on "some filesystems":
>
> /*
>  * If available and useful, use posix_fallocate() (via
>  * FileFallocate()) to extend the relation. That's often more
>  * efficient than using write(), as it commonly won't cause the
> kernel
>  * to allocate page cache space for the extended pages.
>  *
>  * However, we don't use FileFallocate() for small extensions, as
> it
>  * defeats delayed allocation on some filesystems. Not clear where
>  * that decision should be made though? For now just use a cutoff
> of
>  * 8, anything between 4 and 8 worked OK in some local testing.
>  */
> if (numblocks > 8)
>
> I wonder if it wants to be a GUC.
>

Re: Query Discrepancy in Postgres HLL Test

[Adrian Klaver]

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


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.kla...@aklaver.com

Query Discrepancy in Postgres HLL Test

[Ayush Vatsa]

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

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