Re: brininsert optimization opportunity - Mailing list pgsql-hackers

From Soumyadeep Chakraborty
Subject Re: brininsert optimization opportunity
Date
Msg-id CAE-ML+_1nGVH7CitWieLZNR3W54V+RUGG8RQEon5EdEHucGEFw@mail.gmail.com
Whole thread Raw
In response to Re: brininsert optimization opportunity  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: brininsert optimization opportunity
List pgsql-hackers
On Fri, 3 Nov 2023 at 19:37, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote:

> The one thing I'm not entirely sure about is adding new stuff to the
> IndexAmRoutine. I don't think we want to end up with too many callbacks
> that all AMs have to initialize etc. I can't think of a different/better
> way to do this, though.

Yes there is not really an alternative. Also, aminsertcleanup() is very similar
to amvacuumcleanup(), so it is not awkward. Why should vacuum be an
exclusive VIP? :)
And there are other indexam callbacks that not every AM implements. So this
addition is not unprecedented in that sense.

> Barring objections, I'll try to push this early next week, after another
> round of cleanup.

Many thanks for resurrecting this patch!

On Fri, Nov 3, 2023 at 12:16PM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:

>
> I do think we should choose a better namespace than bs_* for the
> fields of BrinInsertState, as BrinBuildState already uses the bs_*
> namespace for its fields in the same file, but that's only cosmetic.
>

bis_* then.

Regards,
Soumyadeep (VMware)



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Version 14/15 documentation Section "Alter Default Privileges"
Next
From: Tomas Vondra
Date:
Subject: Re: Syncrep and improving latency due to WAL throttling