Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
Дата
Msg-id CAHyXU0wEniuEkF39g2qLEYo17zLh6gVjEaFqRfUL4YHEZ=0-KA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?  ("Graeme B. Bell" <graeme.bell@nibio.no>)
Ответы Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
Список pgsql-performance
On Thu, Jul 9, 2015 at 10:12 AM, Graeme B. Bell <graeme.bell@nibio.no> wrote:
>>>
>>> 3. I don't disagree that the benchmark code is objectively 'bad' in the sense that it is missing an important
optimisation.
>>
>> Particularly with regards documentation, a patch improving things is
>> much more likely to improve the situation than griping.  Also,
>> conversation on this list gets recorded for posterity and google is
>> remarkably good at matching people looking for problems with
>> solutions.  So, even in absence of a patch perhaps we've made the
>> lives of future head-scratchers a little bit easier with this
>> discussion.
>
> I agree that patch>gripe, and about the google aspect. But nonetheless, a well-intentioned gripe is > ignorance of a
problem.
>
> As mentioned earlier, I'm sick just now and will be back in hospital again tomorrow & monday, so a patch may be a
littlebit much to ask from me here :-) It's a bit much even keeping up with the posts on the thread so far. 
>
> I might try to fix the documentation a bit later, though as someone with no experience in marking up volatility on
pl/pgsqlfunctions I doubt my efforts would be that great. I also have other OSS project contributions that need some
attentionfirst. 
>
> Re: the google effect. Are these mailing list archives mirrored anywhere, incidentally? For example, I notice we just
losthttp:reddit.com/r/amd at the weekend, all the discussion of the last few years on that forum is out of reach. 

The community maintains it's own mailing list archives in
postgresql.org.  Short of an array of tactical nuclear strikes this is
going to be preserved because it represents the history of the project
and in many ways is as important as the source code itself.

The archives are also mirrored by a number of high quality providers
such as nabble (which tend to beat our archives in google rankings --
likely due to the improved interface).

merlin


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

Предыдущее
От: "Graeme B. Bell"
Дата:
Сообщение: Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
Следующее
От: "Graeme B. Bell"
Дата:
Сообщение: Re: [BUGS] BUG #13493: pl/pgsql doesn't scale with cpus (PG9.3, 9.4)