* Tom Lane ([EMAIL PROTECTED]) wrote: > Stephen Frost <[EMAIL PROTECTED]> writes: > > * Andrew - Supernews ([EMAIL PROTECTED]) wrote: > >> It's not MVCC-safe even with the AccessExclusive lock; > > > This seems like something which should probably be fixed, > > You've missed the point entirely: this *cannot* be fixed, at least not > without giving up the performance advantages that make TRUNCATE > interesting.
Alright, can we give that rather significant performance advantage to
non-owners in some way then? Perhaps as an extra grant right?
This is along the lines of what I was thinking, though I do see that it
gets more complicated when dealing with transactions which started
before the one committing the truncate (Not a problem in my case, but
would have to be dealt with to be MVCC-safe):
TRUNCATE is fast because it knows that it's delete'ing everything and
so it just creates a new (empty) file and deletes the old file. DELETE
goes through the entire file marking each record for deletion and then
the system has to wait around for the vacuum'er to come through and
clean up the file. New transactions using that file have to scan past
all of the deleted tuples until they get vacuumed though. My thinking
is along these lines:
delete from x;/truncate x;
--> Creates a new, empty, file and makes it the 'current' file
--> Marks the old file for deletion, but it is kept around for any
transactions which were started before the truncate;
--> New transactions use the empty file
--> Once all transactions using the old file have completed, the old
file can be deleted.
--> Old transactions which insert rows would need to use the new file
or scan the old file for rows which they added, I suppose.
Thanks,
Stephen
signature.asc
Description: Digital signature
