On 10/16/07, Stéphane Schildknecht
<stephane.schildknecht@postgresqlfr.org> wrote:
> Tom Lane a écrit :
> > =?ISO-8859-1?Q?St=E9phane_Schildknecht?= <stephane.schildknecht@postgresqlfr.org> writes:
> >
> >> For some times, we have a vacuuming process on a specific table that
> >> goes slower and slower. In fact, it took some 3 minutes a month ago, and
> >> now it take almost 20 minutes. But, if one day it take so many time, it
> >> is possible that on the day after it will only take 4 minutes...
> >>
> >
> >
> >> I know the table in concern had 450000 tuples two months ago and now has
> >> more than 700000 tuples in it.
> >>
> >
> > The real question is how often do rows get updated? I suspect you
> > probably need to vacuum this table more than once a day.
> >
> >
>
> To be honest, I suspect it too. But, I have been told by people using
> that database they can't do vacuum more frequently than once in a day as
> it increases the time to achieve concurrent operations.
> That's also why they don't want to hear about autovacuum.
Sounds like somebody there is operating on the belief that vacuums
always cost the same amount i/o wise. With the vacuum_cost_delay
setting Tim mentioned this is not true. Their concern shouldn't be
with how you accomplish your job, but with you meeting certain
performance criteria, and with vacuum cost delay, it is quite possible
to vacuum midday with affecting the db too much.
> And finally that's why I'm looking for everything I can monitor to
> obtain information to convince them they're wrong and I'm right ;-)
Good luck with that. I still have a boss who thinks "vacuum's not
fast enough". His last experience with pgsql was in the 7.2 days.
Generally he's a pretty smart guy, but he's convinced himself that
PostgreSQL 8.3 and 7.2 are pretty much the same beasts.
> That's also why I am so disappointed vacuum doesn't give me these 4
> hints lines.
What kind of error, or output, does it give you at the end? Any hint
as to why they're missing?
