Re: Create unique GiST indexes

From: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, n(dot)bartek3762(at)gmail(dot)com, Peter Eisentraut <peter(at)eisentraut(dot)org>, Warda Bibi <wardabibi221(at)gmail(dot)com>, "Prafulla P(dot) Ranadive" <pprandive(at)gmail(dot)com>
Subject: Re: Create unique GiST indexes
Date: 2026-03-13 20:29:38
Message-ID: CA+renyWWNOBzmfFEEaJL3zw8RRjib3MNDxuhvjf+0b4Dp9eT4g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Fri, Jan 2, 2026 at 10:39 AM Paul A Jungwirth
<pj(at)illuminatedcomputing(dot)com> wrote:
>
> This is the missing MVCC functionality I mentioned when I posted the
> patch. It's the next thing on my list to work on. As I said the patch
> is not really done. But it took longer than I expected to send a reply
> to Matthias, and I wanted to post something before the commitfest
> deadline. And I thought I at least had enough to get feedback on the
> overall approach.
>
> I think your example here would make a great isolation test though.
> I'll incorporate that into future work, or please feel free to write
> it yourself and share if you like.

I realized my approach to this patch is just wrong, because I'm only
searching one index leaf page for conflicts (whichever one the insert
lands on), and they might be in different pages, due to changes in
penalty, splits, and maybe other reasons. I've been working on a
different approach, but I don't have something ready to send in yet.
I've updated the commitfest status to Waiting on Author.

Yours,

--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2026-03-15 14:05:49 BUG #19434: adding WHERE to a publication can cause UPDATEs and DELETEs to fail on the source table
Previous Message Laurenz Albe 2026-03-13 16:37:45 Re: BUG #19432: recovery fails at invalid checkpoint record

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2026-03-13 21:09:33 Re: Better shared data structure management and resizable shared data structures
Previous Message Nathan Bossart 2026-03-13 20:07:29 Re: Add starelid, attnum to pg_stats and leverage this in pg_dump