Re: WIP: cross column correlation ...
От | Rod Taylor |
---|---|
Тема | Re: WIP: cross column correlation ... |
Дата | |
Msg-id | AANLkTin5u=L7o7Kbx8wttcJdiLJBqYjuYzHT697ANQ8f@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: cross column correlation ... (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: WIP: cross column correlation ...
|
Список | pgsql-hackers |
On Fri, Feb 25, 2011 at 14:26, Alvaro Herrera <span dir="ltr"><<a href="mailto:alvherre@commandprompt.com">alvherre@commandprompt.com</a>></span>wrote:<br /><div class="gmail_quote"><blockquoteclass="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204,204); padding-left: 1ex;"> Excerpts from Rod Taylor's message of vie feb 25 14:03:58 -0300 2011:<br /><div class="im"><br/> > How practical would it be for analyze to keep a record of response times for<br /> > given sectionsof a table as it randomly accesses them and generate some<br /> > kind of a map for expected response times forthe pieces of data it is<br /> > analysing?<br /><br /></div>I think what you want is random_page_cost that can betailored per<br /> tablespace.<br /><br /></blockquote></div><br />Yes, that can certainly help but does nothing to helpwith finding typical hot-spots or cached sections of the table and sending that information to the planner.<br /><br/>Between Analyze random sampling and perhaps some metric during actual IO of random of queries we should be able todetermine and record which pieces of data tend to be hot/in cache, or readily available and what data tends not to be.<br/><br /><br />If the planner knew that the value "1" tends to have a much lower cost to fetch than any other valuein the table (it is cached or otherwise readily available), it can choose a plan better suited toward that.<br />
В списке pgsql-hackers по дате отправления: