I didn't mean that we'd want to compress it to the absolute minimum
size. I had envisioned that it would be a simple scheme designed only to
eliminate long runs of identical visibility information (perhaps only
the frozen and always visible regions would be compressed).
The extra level of indirection would be slower, but if we freeze tuples
more aggressively (which would be much cheaper if we didn't have to go
to the heap), there might be a small number of tuples with interesting
visibility information at any particular time.
This should be achievable with current proposal of Heikki, but I think it is useful only for tables which won't have more concurrent operations and on databases without any long running queries. So if we have an option to create a visibiliy map ( on the lines of materialized view ), whenever we want for a table, it would help a good number of use cases, i suppose.
Thanks,
Gokul.