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 ...  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: wCTE: why not finish sub-updates at the end, not the beginning?
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: wCTE: why not finish sub-updates at the end, not the beginning?