Re: Tidy fill hstv array (src/backend/access/heap/pruneheap.c)

Em seg., 4 de mar. de 2024 às 03:18, Andrey M. Borodin <x4mmm(at)yandex-team(dot)ru>
escreveu:

>
>
> > On 14 Jan 2024, at 18:55, John Naylor <johncnaylorls(at)gmail(dot)com> wrote:
> >
> > On Sat, Jan 13, 2024 at 9:36 PM Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
> wrote:
> >>
> >> Em ter., 9 de jan. de 2024 às 06:31, John Naylor <
> johncnaylorls(at)gmail(dot)com> escreveu:
> >
> >>> This just moves an operation from one place to the other, while
> >>> obliterating the explanatory comment, so I don't see an advantage.
> >>
> >> Well, I think that is precisely the case for using memset.
> >> The way initialization is currently done is much slower and harmful to
> the branch.
> >> Of course, the gain should be small, but it is fully justified for
> switching to memset.
> >
> > We haven't seen any evidence or reasoning for that. Simple
> > rules-of-thumb are not enough.
> >
>
> Hi Ranier,
>
> I’ll mark CF entry [0] as “Returned with Feedback”. Feel free to reopen
> item in this CF or submit to the next, if you want to continue working on
> this.
>
> I took a glance into the patch, and I would agree that setting field
> nonzero values with memset() is somewhat unusual. Please provide stronger
> evidence to do so.
>
I counted the calls with non-zero memset in the entire postgres code and
they are about 183 calls.

I counted the calls with non-zero memset in the entire postgres code and
they are about 183 calls.

At least 4 calls with -1

File contrib\pg_trgm\trgm_op.c:
memset(lastpos, -1, sizeof(int) * len);

File src\backend\executor\execPartition.c:
memset(pd->indexes, -1, sizeof(int) * partdesc->nparts);

File src\backend\partitioning\partprune.c:
memset(subplan_map, -1, nparts * sizeof(int));
memset(subpart_map, -1, nparts * sizeof(int));

Does filling a memory area, one by one, with branches, need strong evidence
to prove that it is better than filling a memory area, all at once, without
branches?

best regards,
Ranier Vilela