From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Cc: | Pallav Kalva <pkalva(at)deg(dot)cc>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Poor Performance on a table |
Date: | 2004-12-03 05:57:00 |
Message-ID: | 200412022157.00254.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Pallav,
> Yes, you are right this table is heavily updated, the whole database
> size is of 1.5 gigs, right now i have default fsm settings how much
> should i increase max_fsm_pages and max_fsm_relations to ?
1) fix the table (see below)
2) run the system for another day
3) run VACUUM FULL ANALYZE VERBOSE
4) if you're running 7.4 or better, at the end you'll see a total of FSM pages
needed. If you're running something earlier, you'll need to get out a
calculator and do the math yourself.
Of course, if you're getting heavy update/delete activity, vacuuming more
often might be wise. Post the output of the above command if you have
questions.
> I am hesitant to do vacuum full on the table because it is one of the
> crucial table in our application and we cant afford to have exclusive
> lock on this table for long time. we can afford not to have writes and
> updates but we need atleast reads on this table .
You're going to have to do at least one or the table will just keep getting
worse. Schedule it for 3am. Once you've set FSM correctly, and are
vacuuming with the right frequency, the need to run VACUUM FULL will go away.
Oh, and it's likely that any indexes on the table need to be REINDEXed.
--
Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Karasik | 2004-12-03 10:42:13 | Re: VACUUM ANALYZE downgrades performance |
Previous Message | Vishal Kashyap @ [SaiHertz] | 2004-12-03 05:16:31 | Re: pg replication tools? |