Re: More thoughts about planner's cost estimates
От | Rod Taylor |
---|---|
Тема | Re: More thoughts about planner's cost estimates |
Дата | |
Msg-id | 1149289515.6071.211.camel@home обсуждение исходный текст |
Ответ на | Re: More thoughts about planner's cost estimates (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: More thoughts about planner's cost estimates
|
Список | pgsql-hackers |
> One objection to this is that after moving "off the gold standard" of > 1.0 = one page fetch, there is no longer any clear meaning to the > cost estimate units; you're faced with the fact that they're just an > arbitrary scale. I'm not sure that's such a bad thing, though. For > instance, some people might want to try to tune their settings so that > the estimates are actually comparable to milliseconds of real time. Any chance that the correspondence to time could be made a part of the design on purpose and generally advise people to follow that rule? If we could tell people to run *benchmark* and use those numbers directly as a first approximation tuning, it could help quite a bit for people new to PostgreSQL experiencing poor performance. effective_cache_size then becomes essentially the last hand-set variable for medium sized installations. --
В списке pgsql-hackers по дате отправления: