Re: visualizing B-tree index coverage - Mailing list pgsql-general

From Dann Corbit
Subject Re: visualizing B-tree index coverage
Date
Msg-id D425483C2C5C9F49B5B7A41F89441547055861@postal.corporate.connx.com
Whole thread Raw
In response to visualizing B-tree index coverage  ("TJ O'Donnell" <tjo@acm.org>)
List pgsql-general
Some other things that are important:
How much is the data in transition (updates/deletes/inserts)?  If the
data is mostly static or static you can add many special case indexes
with little penalty.  The biggest cost of indexes (besides disk space
consumed) is in the slowdown of inserts, updates, and deletes.  If the
data hardly changes, you can throw on index after index with little
cost.  But if the data is in huge flux, you will have to be careful
about performance targets for each index you add.

This stuff may prove to be of great value:
http://www.postgresql.org/docs/8.0/interactive/monitoring-stats.html

I would also run EXPLAIN against every distinct sort of query you plan
to execute (unless it is for ad-hoc reporting in which case such a
requirement cannot be met).


pgsql-general by date:

Previous
From: John DeSoi
Date:
Subject: Re: EMBEDDED PostgreSQL
Next
From: "Marc G. Fournier"
Date:
Subject: Good PostgreSQL Based Shopping Cart Software ... ?