| From: | Thomas Pundt <mlists(at)rp-online(dot)de> |
|---|---|
| To: | pgsql-admin(at)postgresql(dot)org |
| Cc: | BRAHMA PRAKASH TIWARI <prakashr2n5(at)gmail(dot)com>, Francesco Andreozzi <francesco(dot)andreozzi(at)gamestorm(dot)it> |
| Subject: | Re: tuning tips, speed problem |
| Date: | 2009-01-19 13:12:06 |
| Message-ID: | 200901191412.07048.mlists@rp-online.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Montag, 19. Januar 2009, BRAHMA PRAKASH TIWARI wrote:
| most probabely this is due to the auto vacuum option on and if auto vacuum
| is on then the in condition of high transaction on database it slows the
| speed of the hole database.Set it off in postgres.conf and vacuum and
| reindex transactional tables manualy with in every two million
| transactions.
| like
| vacuum full <table name>;
| reindex table <table name>;
Please, a "vacuum full" should only be a measure of last resort ever.
Regular vacuum (without the "full" keyword) should always be enough.
And I don't recommend turning autovacuum off.
You might need to increase the "max_fsm_pages" setting to avoid
database bloat. The output of a database wide "vacuum verbose" should
tell you, if it is set appropriately.
And Francesco, if you say
"but on a mysql to execute a simple select with an order by the time was jus
1 or 2 seconds ... on this installation the time it's about 10 seconds or
more",
could you provide the "explain analyze"-output for those queries? This should
help analyzing your problems.
Ciao,
Thomas
--
Thomas Pundt <thomas(dot)pundt(at)rp-online(dot)de> ---- http://rp-online.de/ ----
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marcelo Martins | 2009-01-19 15:38:36 | PostgreSQL monitoring |
| Previous Message | BRAHMA PRAKASH TIWARI | 2009-01-19 12:35:35 | Re: tuning tips, speed problem |