Re: A thought on Index Organized Tables

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>
Cc: heikki(dot)linnakangas(at)enterprisedb(dot)com, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A thought on Index Organized Tables
Date: 2010-02-24 08:30:09
Message-ID: 1267000209.3752.5945.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2010-02-24 08:40:52 Re: A thought on Index Organized Tables
Previous Message Simon Riggs 2010-02-24 08:26:14 Re: Re: [COMMITTERS] pgsql: Move documentation of all recovery.conf option to a new chapter.