Re: define pg_structiszero(addr, s, r) - Mailing list pgsql-hackers

From David Rowley
Subject Re: define pg_structiszero(addr, s, r)
Date
Msg-id CAApHDvrEDWPEyWQF7UhAt+8JR6w2eVpv1xP21FqFH+c=8Lb3JA@mail.gmail.com
Whole thread Raw
In response to Re: define pg_structiszero(addr, s, r)  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
List pgsql-hackers
On Fri, 1 Nov 2024 at 19:33, Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
> Agree, I did a quick test (see [0]) and it looks like it's significantly slower
> using the new inline function.
>
> We could try to write a more elaborate version of pg_memory_is_all_zeros(), but
> as it looks like there is only one use case, then it's probably better to not
> implement (revert) this change here and "just" add a comment as to why pg_memory_is_all_zeros()
> should not be used here, thoughts?

My vote is to just revert this usage of the function. Anything more
elaborate would need to check pointer alignment before using any types
larger than char. The previous code does not need to do that because
the page is going to be at least MAXALIGNed.

David



pgsql-hackers by date:

Previous
From: feichanghong
Date:
Subject: Improve the efficiency of _bt_killitems.
Next
From: Amit Langote
Date:
Subject: Re: Wrong result when enable_partitionwise_join is on if collation of PartitionKey and Column is different.