On Sun, 2003-12-07 at 09:52, Tom Lane wrote:
Steve Wampler [EMAIL PROTECTED] writes:
Hmmm, I have a feeling that's not as obvious as I thought... I can't
identify the index (named 'id_index') in the output of vacuum verbose.
In 7.2, the index reports look like
Index %s: Pages %u;
On Fri, Dec 05, 2003 at 09:54:52PM -0500, Robert Treat wrote:
...
A vacuum verbose could give you a good indication if you need to reindex,
compare the # of pages in the index with the # in the table.
Hmmm, I have a feeling that's not as obvious as I thought... I can't
identify the index
Steve Wampler [EMAIL PROTECTED] writes:
Hmmm, I have a feeling that's not as obvious as I thought... I can't
identify the index (named 'id_index') in the output of vacuum verbose.
In 7.2, the index reports look like
Index %s: Pages %u; Tuples %.0f.
and should appear in the part of the
On Fri, 2003-12-05 at 16:38, Neil Conway wrote:
(1) Can you confirm that the VACUUM FULL on site B actually
removed all the tuples you intended it to remove? Concurrent
transactions can limit the amount of data that VACUUM FULL is
able to reclaim. If you run
I need some help tracking down a sudden, massive slowdown
in inserts in one of our databases.
PG: 7.2.3 (RedHat 8.0)
Background. We currently run nearly identical systems
at two sites: Site A is a 'lab' site used for development,
Site B is a production site.
The databases in question have
Steve Wampler [EMAIL PROTECTED] writes:
PG: 7.2.3 (RedHat 8.0)
You're using PG 7.2.3 with the PG 7.1 JDBC driver; FWIW, upgrading to
newer software is highly recommended.
The two sites were performing at comparable speeds until a few days
ago, when we deleted several million records from
