On Thu, 2010-03-18 at 16:50 -0400, Tom Lane wrote: > The VM is (a) not compressed and (b) not correctness-critical. > Wrong bit values don't do any serious damage.
The VM cause wrong results if a bit is set that's not supposed to be -- right? Am I missing something? How does a seq scan skip visibility checks and still produce right results, if it doesn't rely on the bit? The visibility map would obviously not be very useful if visibility information was randomly distributed among tuples. Whether that qualifies as "compression" or not was not my primary point. The point is that it may be possible to use some structure that is significantly smaller than holding xmin/xmax for every tuple in the heap, and at the same time may be acceptably fast to update. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers