On Mon, Jun 18, 2018 at 4:59 PM Peter Geoghegan <p...@bowt.ie> wrote: > > Note, guaranteed allowable time of index scans (used for quick deletion) > > will be achieved by storing equal-key index tuples in physical TID order [2] > > with patch [3]. > > I now have greater motivation to develop that patch into a real project. > > I bet that my heap-tid-sort patch will allow you to refine your > interface when there are many logical duplicates: You can create one > explicit scan key, but have a list of heap TIDs that need to be killed > within the range of matching index tuples. That could be a lot more > efficient in the event of many non-HOT updates, where most index tuple > values won't actually change. You can sort the list of heap TIDs that > you want to kill once, and then "merge" it with the tuples at the leaf > level as they are matched/killed. It should be safe to avoid > rechecking anything other than the heap TID values. > > [1] > http://pgeoghegan.blogspot.com/2017/07/postgresql-index-bloat-microscope.html > [2] > https://www.postgresql.org/message-id/CAH2-Wzmf6intNY1ggiNzOziiO5Eq=DsXfeptODGxO=2j-i1...@mail.gmail.com
Actually, once btree tids are sorted, you can continue tree descent all the way to the exact leaf page that contains the tuple to be deleted. Thus, the single-tuple interface ends up being quite OK. Sure, you can optimize things a bit by scanning a range, but only if vacuum is able to group keys in order to produce the optimized calls, and I don't see that terribly likely. So, IMHO the current interface may be quite enough.