Re: Tidy fill hstv array (src/backend/access/heap/pruneheap.c) - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Tidy fill hstv array (src/backend/access/heap/pruneheap.c)
Date
Msg-id CAEudQAqfV3xvPFM3d8-Le7WAoBnOANkfwV0Rdab-9WxZtteUAQ@mail.gmail.com
Whole thread Raw
In response to Re: Tidy fill hstv array (src/backend/access/heap/pruneheap.c)  ("Andrey M. Borodin" <x4mmm@yandex-team.ru>)
Responses Re: Tidy fill hstv array (src/backend/access/heap/pruneheap.c)
Re: Tidy fill hstv array (src/backend/access/heap/pruneheap.c)
List pgsql-hackers
Em seg., 4 de mar. de 2024 às 03:18, Andrey M. Borodin <x4mmm@yandex-team.ru> escreveu:


> On 14 Jan 2024, at 18:55, John Naylor <johncnaylorls@gmail.com> wrote:
>
> On Sat, Jan 13, 2024 at 9:36 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
>>
>> Em ter., 9 de jan. de 2024 às 06:31, John Naylor <johncnaylorls@gmail.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

pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: Eager aggregation, take 3
Next
From: John Naylor
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum