Re: [PATCH] set_byte() with a count argument

On Tue, Sep 22, 2026 at 5:55 AM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
>
> On Mon, 21 Sept 2026 at 15:17, Sehrope Sarkuni <sehrope(at)jackdb(dot)com> wrote:
> >
> > Yes, it's possible, but seems clunky and has the extra intermediate
> > alloc for the repeat and decode:
>
> Right, but implementing a repeat() for bytea should remove the alloc
> and memory scan of decode(), and (IMO) would be a more universally
> useful addition.

I'll take a look at that separately as repeat(...) for bytea is
definitely useful.

> Do you have a workload in mind that would hit this operation hard
> enough that the additional allocs (and function calls) becomes a
> significant overhead, or other reasons why overlay's behaviour is
> impractical for your workload?

More the clunkiness than the allocs. I think the intent is
clearer with the count arg.

I was reading through some corruption validation patches and there was
a lot of set_byte(set_byte(set_byte(...))) in the tests. Some of it
was distinct values and overlay(...) was better fit. But a bunch were
all the same value, hence the thought of the additional count arg for
set_byte(...).

> Note, I'm not a huge fan of a 'count' argument in set_byte, as the
> function name implies a singular byte being set.

I always thought of it like memset(...) so the count arg seems natural.

I considered a separate set_bytes(...) but it'd duplicate set_byte(...)
with a count of 1, so the optional arg seemed tidier.

Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/