> On Sep 15, 2025, at 19:23, David Rowley <[email protected]> wrote: > > The attached v3-0001 is the updated v2 patch, and v3-0002 is a POC of > what I described above. Seems there is something to it as the > performance is better. It is a very contrived test case, however. > > create table empty(a int); > create table million (a int); > insert into million select generate_series(1,1000000); > > set max_parallel_Workers_per_gather=0; > set enable_seqscan=0; > set enable_material=0; > set jit=0; > select sum(c) from million m left join lateral (select count(*) c from > empty where ctid in > ('(1,1)','(1,2)','(1,3)','(1,4)','(1,5)','(1,6)','(1,7)','(1,8)','(1,9)','(1,10)','(1,11)','(1,12)','(1,13)','(1,14)','(1,15)','(1,16)','(1,17)','(1,18)','(1,19)','(1,20)','(1,21)','(1,22)','(1,23)','(1,24)','(1,25)','(1,26)','(1,27)','(1,28)','(1,29)','(1,30)','(1,31)','(1,32)','(1,33)','(1,34)','(1,35)','(1,36)','(1,37)','(1,38)','(1,39)','(1,40)','(1,41)','(1,42)','(1,43)','(1,44)','(1,45)','(1,46)','(1,47)','(1,48)','(1,49)','(1,50)','(1,51)','(1,52)','(1,53)','(1,54)','(1,55)','(1,56)','(1,57)','(1,58)','(1,59)','(1,60)','(1,61)','(1,62)','(1,63)','(1,64)','(1,65)','(1,66)','(1,67)','(1,68)','(1,69)','(1,70)','(1,71)','(1,72)','(1,73)','(1,74)','(1,75)','(1,76)','(1,77)','(1,78)','(1,79)','(1,80)','(1,81)','(1,82)','(1,83)','(1,84)','(1,85)','(1,86)','(1,87)','(1,88)','(1,89)','(1,90)','(1,91)','(1,92)','(1,93)','(1,94)','(1,95)','(1,96)','(1,97)','(1,98)','(1,99)','(1,100)')) > on 1=1; >
I just tested v3. V3-0002 looks a nice solution. Now when the first time TidRecheck() is called, “node” is a brand-new one, next time “node” is from the previous recheck, thus it doesn’t need to recalculate TidList. The change also helps the rescan situation by avoiding deleting tss_TidList. So, overall v3 looks good to me. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
