On Thu, Jun 29, 2006 at 12:35:12PM -0400, Tom Lane wrote: > Another issue is that this would replace a simple hint-bit setting with > an index change that requires a WAL entry. There'll be more WAL traffic > altogether from backends retail-deleting index tuples than there would > be from VACUUM cleaning the whole page at once --- and it won't cut the > I/O demand from VACUUM any, either, since VACUUM still has to scan the > index. AFAICS this wouldn't make VACUUM either cheaper or less > necessary, so I'm not sure I see the point.
Ok, I'm going to suggest something that's either radical, or very dumb: does this truncation really need to be xlogged? After all, just like hint bits, nothing is being done that won't be recovered from later if it doesn't happen. The only possible thing I can imagine is that during xlog replay you end up trying to add more tuples than appear to fit. But if you have a vacuum page procedure you could call it again to try to compress it down. Then again, perhaps visibility checks are not safe within xlog replay state. I'm hoping that overall disk traffic reduces because total disk space used by tables/indexes reduces. > 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. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature
