Re: define pg_structiszero(addr, s, r)
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
Peter Smith <smithpb2250@gmail.com>, Peter Eisentraut <peter@eisentraut.org>,
Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers@lists.postgresql.org
Date: 2024-11-01T07:27:45Z
Lists: pgsql-hackers
On Fri, 1 Nov 2024 at 20:14, Michael Paquier <michael@paquier.xyz> wrote: > 2) On HEAD at 49d6c7d8daba: > .LVL299: > .loc 1 131 16 is_stmt 0 discriminator 1 view .LVU524 > cmpq $8192, %rbx > je .L419 > > 3) With the patch sent at [1]: > .LVL306: > .loc 3 201 23 is_stmt 1 discriminator 1 view .LVU545 > cmpq $8192, %rbx > jne .L417 > > So it does not matter one way or another for 2) or 3), does it? The patch in [1] will fix the bug. But I'm still concerned about the performance implications of moving to byte-at-a-time processing. There are about 8 times more instructions being expected to do the same work. David > [1]: https://www.postgresql.org/message-id/ZyR02ofHiWG1HmLI@paquier.xyz
Commits
-
Use pg_memory_is_all_zeros() in PageIsVerifiedExtended()
- 03a42c9652f8 18.0 landed
-
Optimize pg_memory_is_all_zeros() in memutils.h
- 5be1dabd2ae0 18.0 landed
-
Remove use of pg_memory_is_all_zeros() in bufpage.c
- e819bbb7c82a 18.0 landed
-
Add pg_memory_is_all_zeros() in memutils.h
- 07e9e28b56db 18.0 landed