From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Juan Jose Comellas <juanjo(at)comellas(dot)com(dot)ar> |
Cc: | <pgsql-general(at)postgresql(dot)org>, Francisco Ezcurra <fezcurra(at)novamens(dot)com>, Alexis Rodriguez <alexis(at)novamens(dot)com> |
Subject: | Re: VACUUM FULL not working with persistent connections |
Date: | 2002-10-28 16:53:03 |
Message-ID: | 20021028085004.J79386-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 24 Oct 2002, Juan Jose Comellas wrote:
> The problem is that Postgres seems to be making a logical delete for each row
> that is updated (i.e. it seems to be doing an INSERT followed by a DELETE),
> so a lot of cruft is created on the database. We need to avoid this because
> there are other processes that are permanently querying this table (normally
> needing a sequential scan over the table) and the performance of the queries
> gradually decreases with each update. We run a VACUUM ANALYZE every 30
> minutes on this table and with v7.1.3 the system performs acceptably. With
> v7.2 (we tried v7.2.1, v7.2.2 and v7.2.3) if we run a VACUUM FULL ANALYZE on
> the table almost none of the deleted rows are really vacuumed until the
> clients disconnect. When using the VERBOSE modifier, I noticed that sometimes
> some of the rows were effectively removed, but these we normally very few
> (less than 10%). We even tried a VACUUM FULL FREEZE ANALYZE without success.
Are the persistent connections staying idle in a transaction or outside of
one? If it were in one, I could see this, although I don't wee why it'd
be different from 7.1.x.
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2002-10-28 16:59:17 | Re: Why does postgres seach in ALL lines (not optimal!) |
Previous Message | Stephan Szabo | 2002-10-28 16:45:40 | Re: Help me please ! |