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
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 |