On Thu, Mar 17, 2011 at 4:02 PM, Jesper Krogh <jesper@krogh.cc> wrote:
> On the 1 bit per page the "best case" would be 341 times better than above
> reducing the size of the visibiility map on a 10GB table to around 152KB
> which
> is extremely small (and thus also awesome) But the consequenses of a single
> update would mean that you loose visibilllity map benefit on 341 tuples in
> one shot.
True, but I'm not really sure that matters very much. Keep in mind
also that would increase the frequency with which visibility map bits
would need to be flipped, which would carry its own costs.
> Worst case situations are, where we approach the 4 tuples per page, before
> we hit toast where the ratio of space reduction in 1 bit per tuple would be:
> 1:(2048x8) ~ 1:16384 and the 1 bit per page is 4 times better.
> In the 1 bit per tuple a visibillity map of a 10GB relation would be around
> 610KB
> 1 bit per page would then drop it to around 160KB.
>
>
> Can we drag out some average-case numbers on row-size in the heap
> from some real production systems?
Well, unless you went to some significantly more complicated data
structure, you'd need to allow room for the maximum number of tuples
per page on every page, whether the slots were all in use or not.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
