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.
>
>
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 |