Re: brininsert optimization opportunity

From: Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Ashwin Agrawal <ashwinstar(at)gmail(dot)com>
Subject: Re: brininsert optimization opportunity
Date: 2023-07-05 18:57:58
Message-ID: CAE-ML+9JVD3vt7JZtmNy8hOFQKtP2jxJtf27=kE=ViGyv36V3w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 5, 2023 at 3:16 AM Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:

> > I'll try this out and introduce a couple of new index AM callbacks. I
> > think it's best to do it before releasing the locks - otherwise it
> > might be weird
> > to manipulate buffers of an index relation, without having some sort of lock on
> > it. I'll think about it some more.
> >
>
> I don't understand why would this need more than just a callback to
> release the cache.

We wouldn't. I thought that it would be slightly cleaner and slightly more
performant if we moved the (if !state) branches out of the XXXinsert()
functions.
But I guess, let's minimize the changes here. One cleanup callback is enough.

> > PS: It should be possible to make GIN and GiST use the new index AM APIs
> > as well.
> >
>
> Why should GIN/GiST use the new API? I think it's perfectly sensible to
> only require the "cleanup callback" when just pfree() is not enough.

Yeah no need.

Attached v3 of the patch w/ a single index AM callback.

Regards,
Soumyadeep (VMware)

Attachment Content-Type Size
v3-0001-Reuse-revmap-and-brin-desc-in-brininsert.patch text/x-patch 13.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alena Rybakina 2023-07-05 19:39:08 Re: POC, WIP: OR-clause support for indexes
Previous Message Thom Brown 2023-07-05 18:08:49 Re: Allow specifying a dbname in pg_basebackup connection string