=?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. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

=?ISO-8859-1?Q?St=E9phane_Schildknecht?= <stephane.schildknecht@postgresqlfr.org> writes: > Tom Lane a écrit : >> 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. vacuum_cost_delay can help here. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate

"Scott Marlowe" <scott.marlowe@gmail.com> writes: > On 10/16/07, St=E9phane Schildknecht > <stephane.schildknecht@postgresqlfr.org> wrote: >> 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? If you're talking about the FSM statistics display, that only gets printed by a database-wide VACUUM (one that doesn't name a specific table). regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly

=?ISO-8859-1?Q?St=E9phane_Schildknecht?= <stephane.schildknecht@postgresqlfr.org> writes: > Yes, I am. The command line is (in a shell script whom ouput is > redirected in a global file) : > vacuumdb -d $DBNAME -p $DBPORT -U $DBUSR -z -v > That does not explain why we don't get FSM statitics display. Is $DBUSR a superuser? If not, some tables are likely getting skipped. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Alvaro Herrera <alvherre@commandprompt.com> writes: > What would be really useful is to remove all that noise from vacuum and > make it appear on a view. Well, if you want something decoupled from VACUUM there's already contrib/pg_freespacemap. > 8.4 material all of this, of course. I am hoping that we rewrite FSM into the distributed DSM structure that's been talked about, so that the whole problem goes away in 8.4. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match