Re: degenerate performance on one server of 3

From: Tom Lane
Subject: Re: degenerate performance on one server of 3
Date: ,
Msg-id: 16593.1243865172@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: degenerate performance on one server of 3  (Erik Aronesty)
Responses: Re: degenerate performance on one server of 3  (Erik Aronesty)
List: pgsql-performance

Tree view

degenerate performance on one server of 3  (Erik Aronesty, )
 Re: degenerate performance on one server of 3  (Tom Lane, )
  Re: degenerate performance on one server of 3  (Craig Ringer, )
   Re: degenerate performance on one server of 3  (Tom Lane, )
    Re: degenerate performance on one server of 3  (Erik Aronesty, )
     Re: degenerate performance on one server of 3  (Tom Lane, )
      Re: degenerate performance on one server of 3  (Erik Aronesty, )
       Re: degenerate performance on one server of 3  (Tom Lane, )
       Re: degenerate performance on one server of 3  (Reid Thompson, )
        Re: degenerate performance on one server of 3  (Erik Aronesty, )
         Re: degenerate performance on one server of 3  (Robert Haas, )
          Re: degenerate performance on one server of 3  (Scott Carey, )
         Re: degenerate performance on one server of 3  (Scott Carey, )
          Re: degenerate performance on one server of 3  (Erik Aronesty, )
         Re: degenerate performance on one server of 3  (Robert Haas, )

Erik Aronesty <> writes:
> but why wasn't autovac enough to reclaim at least *most* of the space?

Autovac isn't meant to reclaim major amounts of bloat; it's more in the
line of trying to prevent it from happening in the first place.  To
reclaim bloat it would have to execute VACUUM FULL, or some other
operation that requires exclusive table lock, which doesn't seem like
a good idea for an automatic background operation.

            regards, tom lane


pgsql-performance by date:

From: Scott Carey
Date:
Subject: Re: Scalability in postgres
From: Robert Haas
Date:
Subject: Re: Unexpected query plan results