Re: define pg_structiszero(addr, s, r)

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: define pg_structiszero(addr, s, r)
Date: 2024-11-13 00:51:23
Message-ID: CAEudQApWsEr05z4vr+ckv6fvhnHGWh+0pT1eqyJVzS6yvyPHXQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em ter., 12 de nov. de 2024 às 21:33, Michael Paquier <michael(at)paquier(dot)xyz>
escreveu:

> On Tue, Nov 12, 2024 at 01:32:36PM -0300, Ranier Vilela wrote:
> > See v1_allzeros_small.c attached.
>
> In your pg_memory_is_all_zeros_v11:
> while (((uintptr_t) p & (sizeof(size_t) - 1)) != 0)
> {
> if (p == end)
> return true;
>
> if (*p++ != 0)
> return false;
> }
>
> if (len > sizeof(size_t) * 8)
> {
> for (; p < aligned_end - (sizeof(size_t) * 7); p += sizeof(size_t) *
> 8)
> {
> if ((((size_t *) p)[0] != 0) | (((size_t *) p)[1] != 0) |
> (((size_t *) p)[2] != 0) | (((size_t *) p)[3] != 0) |
> (((size_t *) p)[4] != 0) | (((size_t *) p)[5] != 0) |
> (((size_t *) p)[6] != 0) | (((size_t *) p)[7] != 0))
> return false;
> }
> }
>
> If I'm reading that right, this could still read a couple of bytes
> past the wanted memory area.

Yeah, this is possible.

> For example, imagine a case of 65 bytes
> with a location a bit unaligned (more than 2 bytes). You'd want to
> check the remaining size after the first loop, not the initial one.
>
> I'd be OK to have a quick loop for the less-than-64-byte case rather
> than more checks depending on sizeof(size_t) spread, like Bertrand is
> suggesting.

I'm ok too. Maybe we are trying to optimize early.

best regards,
Ranier Vilela

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2024-11-13 01:58:57 Re: Fix to increment the index scan counter for the bloom filter index
Previous Message Masahiro Ikeda 2024-11-13 00:45:04 Re: Fix to increment the index scan counter for the bloom filter index