Re: When creating index, why pointing to old version of tuple

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Tender Wang <tndrwang(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: When creating index, why pointing to old version of tuple
Date: 2025-08-01 08:13:46
Message-ID: CAEoWx2kNa-feGKwk3tOrMtwLjGf3T-WfTPOfQPnk-_J6z9ai4w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

This explanation sounds reasonable to me. I didn't mean to "optimize" the
logic, I was just trying to understand the behavior.

Chao Li (Evan)
------------------------------
HighGo Software Inc.
https://www.highgo.com/

David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> 于2025年8月1日周五 15:50写道:

> On Friday, August 1, 2025, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
>>
>> > But what if the table already has an index?
>>
>> I have tested that, if I create the index first, then update the tuple,
>> the index entry will only point to the new version of data. That's why my
>> question was specifically about creating the index after updating the tuple.
>>
>
> IIUC it’s just a seemingly low-value optimization that no one has bothered
> to implement. The code path in question handles both initial creation and
> reindexing and the later needs to keep the chain intact for concurrent
> readers. It just doesn’t seem worth it to offer 10% off new index
> creations and then charging full price thereafter. It could actually be a
> bit counter-productive since your initial evaluation period would be skewed
> toward the positive.
>
> David J.
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-08-01 08:22:52 Re: implement CAST(expr AS type FORMAT 'template')
Previous Message Chao Li 2025-08-01 08:10:16 Re: Raw parse tree is not dumped to log