Re: Optimizing ResouceOwner to speed up COPY

On 10/27/25 16:14, Tomas Vondra wrote:
> On 10/21/25 16:43, Tomas Vondra wrote:
>> ...
>>
>> The results seem fairly stable, and the overall trend is clear. It'd be
>> great if there were no regressions, but considering how narrow is this
>> microbenchmark (and considering the benefits for practical COPY runs),
>> I'd say it's probably OK.
>>
>
> The regression for non-pathological cases (like COPY) is bothering me,
> even if it's a very narrow microbenchmark and I'd bet it would not be
> measurable in practice. Still, it's annoying.
>
> I wonder if maybe a better solution would be to invent a concept of
> tuple slots for the same descriptor, and allow it to be tracked only
> once in the resource owner. That'd mean no duplicates, completely
> eliminating the pathological case.
>

Here's a PoC of this approach. It introduces a couple functions to
create/destroy a batch of slots, and uses that for COPY.

After allocating a batch with table_slot_batch_create(), the code can
get the next slot using table_slot_batch_next(). The descriptor is
pinned only once, in table_slot_batch_create().

It needs to add these to multiple "layers", but it's mostly mechanical.
It's just a PoC and needs more thought / cleanup. E.g. some of the
duplication could be eliminated (if we allowed MakeTupleTableSlot to
skip pinning the descriptor). Also, perhaps there should be a way to
protect against freeing the batched slots individually.

Anyway, the results are unsurprising - it has the same benefits as the
earlier patches, but doesn't affect the resownerbench at all.

regards

--
Tomas Vondra