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: | Raw Message | Whole Thread | 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 |