Re: Parallel Seq Scan

Поиск
Список
Период
Сортировка
От Thom Brown
Тема Re: Parallel Seq Scan
Дата
Msg-id CAA-aLv4cPHaeGWZz3XW2rhrs=cBkf=F3SaW7acAreuSNeTmE7g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 28 January 2015 at 14:03, Robert Haas <span
dir="ltr"><<ahref="mailto:robertmhaas@gmail.com" target="_blank">robertmhaas@gmail.com</a>></span> wrote:<br
/><blockquoteclass="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The problem
here,as I see it, is that we're flying blind.  If there's<br /> just one spindle, I think it's got to be right to read
therelation<br /> sequentially.  But if there are multiple spindles, it might not be,<br /> but it seems hard to
predictwhat we should do.  We don't know what<br /> the RAID chunk size is or how many spindles there are, so any guess
as<br/> to how to chunk up the relation and divide up the work between workers<br /> is just a shot in the
dark.</blockquote></div><br/></div><div class="gmail_extra">Can't the planner take effective_io_concurrency into
account?<brclear="all" /></div><div class="gmail_extra"><br /><div class="gmail_signature">Thom</div></div></div> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: hung backends stuck in spinlock heavy endless loop
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Safe memory allocation functions