From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Torsten Förtsch <torsten(dot)foertsch(at)gmx(dot)net>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: planner parameters |
Date: | 2013-09-03 19:02:00 |
Message-ID: | 1378234920.66126.YahooMailNeo@web162906.mail.bf1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Torsten Förtsch <torsten(dot)foertsch(at)gmx(dot)net> wrote:
> Is there an other way to make the planner use generate the 1st
> plan?
The planner cost factors are based on the assumption that a
moderate percentage of random page reads will need to actually go
out to disk. If a high percentage of pages are in cache, you may
want to reduce random_page_cost to something closer to (or even
equal to) seq_page_cost. I generally find I get better plans if I
raise cpu_tuple_cost to 0.03. effective_cache_size should
generally be between 50% and 75% of machine RAM. If these changes
(or others of their ilk) cause costs to be estimated in a way which
more nearly matches reality, better plans will be chosen.
> Why does it generate the 2nd plan at all?
It has the lowest estimated cost, based on your memory
configuration and cost factors.
> Does the planner take into account what is currently present in
> shared memory?
No. If you search the archives you can probably find previous
discussions of whether it would be a good idea to do so; the
consensus has been that it would not be.
If you have further performance-related questions, please review
this page so that you can provide enough information to allow
people to give the most helpful advice:
http://wiki.postgresql.org/wiki/SlowQueryQuestions
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Jesper Krogh | 2013-09-03 19:34:10 | Re: Slow query-plan generation (fast query) PG 9.2 |
Previous Message | Vitalii Tymchyshyn | 2013-09-03 19:00:53 | Re: Varchar vs foreign key vs enumerator - table and index size |