Peter Schuller wrote: > I have only looked very very briefly at the PG code so I don't know > how far fetched it is, but my thought was that it should be possible > to have a slow background process (similar to normal non-full vacuums > nows) that would, instead of registering dead tuples in the FSM, move > live tuples around. What you've described is actually very close to VACUUM FULL. VACUUM FULL needs to take an exclusive lock to lock out concurrent scanners that might miss or see a tuple twice, when a live tuple is moved. That's the fundamental problem you need to solve. I think it's doable, if you take a copy of the tuple, and set the ctid pointer on the old one like an UPDATE, and wait until the old tuple is no longer visible to anyone before removing it. It does require some changes to tuple visibility code. For example, a transaction running in serializable mode shouldn't throw a serialization error when it tries to update an old, moved row version, but follow the ctid pointer instead. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
