Re: Using indexUnchanged with nbtree

2021-10-01 Thread Simon Riggs
On Fri, 1 Oct 2021 at 15:20, Jaime Casanova wrote: > This has been stalled since July, and based on Peter's comment i feel we > should mark this as RwF. Which i'm doing now. > > Please feel free to resubmit for Next Commitfest. Agreed, thank you Jaime. -- Simon Riggshttp://www.

Re: Using indexUnchanged with nbtree

2021-10-01 Thread Jaime Casanova
On Thu, Jul 01, 2021 at 09:22:38AM -0700, Peter Geoghegan wrote: > On Thu, Jul 1, 2021 at 8:23 AM Simon Riggs > wrote: > > Definitely some good ideas here. > > I have been meaning to come up with some kind of solution to the > problem of "self-blocking" LP_DEAD bit setting within the > kill_prio

Re: Using indexUnchanged with nbtree

2021-07-01 Thread Peter Geoghegan
On Thu, Jul 1, 2021 at 8:23 AM Simon Riggs wrote: > Definitely some good ideas here. I have been meaning to come up with some kind of solution to the problem of "self-blocking" LP_DEAD bit setting within the kill_prior_tuple mechanism. It's hard to argue against that. > I'm out of time to do any

Re: Using indexUnchanged with nbtree

2021-07-01 Thread Simon Riggs
On Fri, Jun 25, 2021 at 4:44 PM Peter Geoghegan wrote: > > On Fri, Jun 25, 2021 at 1:43 AM Simon Riggs > wrote: > > Seems a little bizarre to have _bt_check_unique() call back into the > > heap block we literally just unpinned. > > I suppose it is a little bizarre. > > > This is another case of t

Re: Using indexUnchanged with nbtree

2021-06-25 Thread Peter Geoghegan
On Fri, Jun 25, 2021 at 1:43 AM Simon Riggs wrote: > Seems a little bizarre to have _bt_check_unique() call back into the > heap block we literally just unpinned. I suppose it is a little bizarre. > This is another case of the UPDATE scan and later heap/index > insertions not working together ve

Re: Using indexUnchanged with nbtree

2021-06-25 Thread Simon Riggs
On Fri, Jun 25, 2021 at 2:34 AM Peter Geoghegan wrote: > > On Thu, Jun 24, 2021 at 5:39 AM Simon Riggs > wrote: > > This case occurs when we are doing non-HOT UPDATEs. That command is > > searched, so the scan will already have touched the heap and almost > > certainly the index also, setting any

Re: Using indexUnchanged with nbtree

2021-06-24 Thread Peter Geoghegan
On Thu, Jun 24, 2021 at 5:39 AM Simon Riggs wrote: > This case occurs when we are doing non-HOT UPDATEs. That command is > searched, so the scan will already have touched the heap and almost > certainly the index also, setting any LP_DEAD bits already in the most > frequent case. But it won't, be

Re: Using indexUnchanged with nbtree

2021-06-24 Thread Simon Riggs
On Wed, Jun 23, 2021 at 5:42 PM Peter Geoghegan wrote: > > On Wed, Jun 23, 2021 at 9:31 AM Simon Riggs > wrote: > > You're right that skipping the check might also skip killing a prior > > row version, but it doesn't prevent later scans from killing them, so > > there is no correctness aspect to

Re: Using indexUnchanged with nbtree

2021-06-23 Thread Peter Geoghegan
On Wed, Jun 23, 2021 at 9:31 AM Simon Riggs wrote: > You're right that skipping the check might also skip killing a prior > row version, but it doesn't prevent later scans from killing them, so > there is no correctness aspect to that. Probably not, no. I'll assume for now that there is no correc

Re: Using indexUnchanged with nbtree

2021-06-23 Thread Simon Riggs
On Wed, Jun 23, 2021 at 5:17 PM Peter Geoghegan wrote: > > On Mon, Jun 21, 2021 at 5:31 AM Simon Riggs > wrote: > > Seems like we can skip the uniqueness check if indexUnchanged, which > > will speed up non-HOT UPDATEs on tables with B-Trees. > > I thought about doing this myself. Never got as fa

Re: Using indexUnchanged with nbtree

2021-06-23 Thread Peter Geoghegan
On Mon, Jun 21, 2021 at 5:31 AM Simon Riggs wrote: > Seems like we can skip the uniqueness check if indexUnchanged, which > will speed up non-HOT UPDATEs on tables with B-Trees. I thought about doing this myself. Never got as far as thinking about the correctness implications in detail. One thin