
> > ???? Isn't current implementation "bulk delete" ?
> 
> No, the index AM is called separately for each index tuple to be
> deleted; more to the point, the search for deletable index tuples
> should be moved inside the index AM for performance reasons.

Wouldn't a sequential scan on the heap table be the fastest way to find
keys, that need to be deleted ?

foreach tuple in heap that can be deleted do:
	foreach index
		call the current "index delete" with constructed key and xtid

The advantage would be, that the current API would be sufficient and
it should be faster. The problem would be to create a correct key from the heap
tuple, that you can pass to the index delete function.

Andreas

Fri, 18 May 2001 12:13:55 +0200
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: Plans for solving the VACUUM problem 
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at> writes:
> foreach tuple in heap that can be deleted do:
> 	foreach index
> 		call the current "index delete" with constructed key and xtid

See discussion with Hiroshi.  This is much more complex than TID-based
delete and would be faster only for small numbers of tuples.  (Very
small numbers of tuples, is my gut feeling, though there's no way to
prove that without implementations of both in hand.)

A particular point worth making is that in the common case where you've
updated the same row N times (without changing its index key), the above
approach has O(N^2) runtime.  The indexscan will find all N index tuples
matching the key ... only one of which is the one you are looking for on
this iteration of the outer loop.

			regards, tom lane

Fri, 18 May 2001 09:47:55 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: Plans for solving the VACUUM problem 