Martijn van Oosterhout wrote: > > You can't truncate a tuple to just the header, or at least it's not > > going to be very useful to do it, unless you can also move other tuples > > to coalesce the free space on the page. Which means you need a > > VACUUM-strength page lock. If you're trying to do this in foreground > > queries, you get into the same performance and deadlock issues I already > > mentioned. And I think the net-increase-in-WAL-traffic point would > > apply too, since VACUUM will still need to clean the page when it > > removes the header. > > Well, I was only thinking of having the bgwriter do it in the > background, just bfore writing the block to disk. I'm hoping that it > only tries to write out pages not recently used, so hopefully there > would be very little contention there. > > And perhaps you can avoid the xlogging for the same reason as I > suggested above.
Non-visible members of the SITC chains could also removed by the background writer. Adding to the chain does not require a vacuum-level lock; only reusing the space requires it. The thing that has always held us back from more aggressive tuple reuse is the inability of vacuum to do small cleanups --- it has to scan indexes so it wants to do many pages at once. If you have SITC, there are new possibilities for tuple reuse. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly