Re: VACUUM FULL not working with persistent connections

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.

In response to

Responses

Browse pgsql-general by date

  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 !