From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Greg Burd <greg(at)burd(dot)me>, "Burd, Greg" <gregburd(at)amazon(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Expanding HOT updates for expression and partial indexes |
Date: | 2025-10-09 19:27:15 |
Message-ID: | ea98b11380557874a7bf3a577146786df8ec1da1.camel@j-davis.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2025-10-07 at 17:36 -0400, Greg Burd wrote:
> After reviewing how updates work in the executor, I discovered that
> during execution the new tuple slot is populated with the information
> from ExecBuildUpdateProjection() and the old tuple, but that most
> importantly for this use case that function created a bitmap of the
> modified columns (the columns specified in the update). This bitmap
> isn't the same as the one produced by HeapDetermineColumnsInfo() as
> the
> latter excludes attributes that are not changed after testing
> equality
> with the helper function heap_attr_equals() where as the former will
> include attributes that appear in the update but are the same value
> as
> before. This, happily, is immaterial for the purposes of my function
> ExecExprIndexesRequireUpdates() which simply needs to check to see if
> index tuples generated are unchanged. So I had all I needed to run
> the
> checks ahead of acquiring the lock on the buffer.
You're still calling ExecExprIndexesRequireUpdates() from within
heap_update(). Can't you do that inside of ExecUpdatePrologue() or
thereabouts?
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2025-10-09 19:33:33 | Re: [PATCH] Add tests for Bitmapset |
Previous Message | Srinath Reddy Sadipiralla | 2025-10-09 19:09:43 | Re: Making pg_rewind faster |