Re: Parallel Seq Scan

Поиск
Список
Период
Сортировка
От Stefan Kaltenbrunner
Тема Re: Parallel Seq Scan
Дата
Msg-id 54B29B06.8010105@kaltenbrunner.cc
обсуждение исходный текст
Ответ на Re: Parallel Seq Scan  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On 01/11/2015 11:27 AM, Stephen Frost wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Thu, Jan 8, 2015 at 2:46 PM, Stephen Frost <sfrost@snowman.net> wrote:
>>> Yeah, if we come up with a plan for X workers and end up not being able
>>> to spawn that many then I could see that being worth a warning or notice
>>> or something.  Not sure what EXPLAIN has to do anything with it..
>>
>> That seems mighty odd to me.  If there are 8 background worker
>> processes available, and you allow each session to use at most 4, then
>> when there are >2 sessions trying to do parallelism at the same time,
>> they might not all get their workers.  Emitting a notice for that
>> seems like it would be awfully chatty.
> 
> Yeah, agreed, it could get quite noisy.  Did you have another thought
> for how to address the concern raised?  Specifically, that you might not
> get as many workers as you thought you would?

Wild idea: What about dealing with it as some sort of statistic - ie
track some global counts in the stats collector or on a per-query base
in pg_stat_activity and/or through pg_stat_statements?

Not sure why it is that important to get it on a per-query base, imho it
is simply a configuration limit we have set (similiar to work_mem or
when switching to geqo) - we dont report "per query" through
notice/warning there either (though the effect is kind visible in explain).


Stefan



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

Предыдущее
От: Ravi Kiran
Дата:
Сообщение: Hash Function
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Using 128-bit integers for sum, avg and statistics aggregates