On Wed, 2010-02-24 at 13:50 +0530, Gokulakannan Somasundaram wrote:
> Please consider my following statements from a database tuner
> perspective. I don't want to discourage the visibility map feature,
> but it has the disadvantages, which we already discussed. While i do a
> explain analyze and i see 300 reads, but the same query in production
> might lead to 400 reads(with all the extra 100 being random i/os),
> because of the state of the visibility map. If there is a long batch
> job running somewhere in the database, it will affect almost all the
> visibility maps of the relation. So how can a person, tune and test a
> query in dev and put it in production and be confident about the i/o
> performance ? Say Visibility map goes into core after 9.x, the
> performance of those databases will be less compared to the previous
> release in these circumstances.
I would add that both Heikki and Greg Stark have argued at length that
the visibility map cannot be relied upon in production systems. Those
arguments were deployed when considering the use of the VM for
partitioning, yet they apply equally to use of the VM in other contexts.
The fragility there is not an issue in a mostly read-only application,
but it definitely would be a concern in other cases.
-- Simon Riggs www.2ndQuadrant.com