On Mon, Oct 20, 2003 at 05:42:52PM -0400, Tom Lane wrote:
hold of these dead rows instead of recycling them. I suspect you have
a client process somewhere that is holding an open transaction for a
long time ... probably not doing anything, just sitting there with an
unclosed BEGIN ...
Which
Andrew Sullivan wrote:
On Mon, Oct 20, 2003 at 05:42:52PM -0400, Tom Lane wrote:
hold of these dead rows instead of recycling them. I suspect you have
a client process somewhere that is holding an open transaction for a
long time ... probably not doing anything, just sitting there with an
Hi Tom,
1.)
OK. We have narrowed it down.
We did a few (like 5 to 8 times) vacuum analyze tablename (no full), the
pg_statistics relfilenode grew. There was no database operation when
we did this, no other client connections except the one that does
the vacuum.
If we do plain simple vacuum
Seum-Lim Gan [EMAIL PROTECTED] writes:
We did a few (like 5 to 8 times) vacuum analyze tablename (no full), the
pg_statistics relfilenode grew.
Well, sure. ANALYZE puts new rows into pg_statistic, and obsoletes old
ones. You need to vacuum pg_statistic every so often (not to mention
the other
Hi Tom, Josh,
We tried one more thing: with the table not being updated
at all and we did vacuum. Each time a vacuum is done,
the index file becomes bigger.
This is probably what is contributing to the index file
growing as well.
Thanks.
Gan
At 11:04 am -0500 2003/10/20, Seum-Lim Gan wrote:
Hi
Seum-Lim Gan [EMAIL PROTECTED] writes:
We tried one more thing: with the table not being updated
at all and we did vacuum. Each time a vacuum is done,
the index file becomes bigger.
It is not possible for plain vacuum to make the index bigger.
VACUUM FULL possibly could make the index bigger,
Seum-Lim Gan [EMAIL PROTECTED] writes:
[ successive outputs from VACUUM ANALYZE ]
FWIW, I don't think your problem is really index bloat at all, it's
more like too-many-dead-rows bloat. Note that the number of dead row
versions is climbing steadily from run to run:
DETAIL: 101802 dead row
Hi Tom,
Thanks for info. I stoped the update and removed the process that's doing
the update and did vacuum analyze. This time the result says
the index row has been removed :
vacuum verbose analyze dsperf_rda_or_key;
INFO: vacuuming scncraft.dsperf_rda_or_key
INFO: index dsperf242_1105 now
Seum-Lim Gan [EMAIL PROTECTED] writes:
vacuum verbose analyze dsperf_rda_or_key;
INFO: vacuuming scncraft.dsperf_rda_or_key
INFO: index dsperf242_1105 now contains 30 row versions in 12387 pages
DETAIL: 3097702 index row versions were removed.
0 index pages have been deleted, 0 are
Hi Josh,
Sample verbose analyze:
VACUUM VERBOSE ANALYZE hello_rda_or_key;
INFO: vacuuming craft.hello_rda_or_key
INFO: index hello242_1105 now contains 740813 row versions in 2477 pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 0.42s/0.13u sec elapsed 4.76 sec.
Seum-Lim Gan [EMAIL PROTECTED] writes:
Sample verbose analyze:
VACUUM VERBOSE ANALYZE hello_rda_or_key;
INFO: vacuuming craft.hello_rda_or_key
INFO: index hello242_1105 now contains 740813 row versions in 2477 pages
So what's the problem? That doesn't seem like a particularly bloated
Hi Tom,
I did that when I have stopped my updates.
Now, I am doing updates below is the output of vacuum.
After doing the vacuum verbose analyze, it reported the following :
INFO: vacuuming craft.dsperf_rda_or_key
INFO: index hello242_1105 now contains 1792276 row versions in 6237 pages
Seum-Lim Gan [EMAIL PROTECTED] writes:
INFO: vacuuming craft.dsperf_rda_or_key
INFO: index hello242_1105 now contains 1792276 row versions in 6237 pages
DETAIL: 0 index pages have been deleted, 0 are currently reusable.
CPU 0.61s/0.36u sec elapsed 17.92 sec.
INFO: hello_rda_or_key: found
13 matches
Mail list logo
