| From: | "Josh Berkus" <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Rod Taylor <rbt(at)rbt(dot)ca>, Mike Nielsen <miken(at)bigpond(dot)net(dot)au> |
| Cc: | Postgresql performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Query performance discontinuity |
| Date: | 2002-11-12 16:57:43 |
| Message-ID: | web-1822582@davinci.ethosmedia.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Mike,
> Given the estimated costs, PostgreSQL is doing the right things.
>
> However, in your case, it doesn't appear that the estimations are
> realistic. Index scans are much cheaper than advertised.
Can I assume that you've run VACUUM FULL ANALYZE on the table, or
preferably the whole database?
>
> Try setting your random_page_cost lower (1.5 to 2 rather than 4).
> Bumping sortmem to 32 or 64MB (if plenty of ram is available) will
> help
> most situations.
>
> Might see the 'pg_autotune' project for assistance in picking good
> values.
>
> http://gborg.postgresql.org/project/pgautotune/projdisplay.php
Um. I don't think we have anything to advertise yet, for pg_autotune.
It's still very much an alpha, and the limits we set are pretty
arbitrary.
-Josh Berkus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | scott.marlowe | 2002-11-12 17:22:54 | Re: Upgrade to dual processor machine? |
| Previous Message | Jirka Novak | 2002-11-12 07:30:05 | Re: Slow response from 'SELECT * FROM table' |