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 CAHyXU0wBQjvvyMhpi5VWCGUWX07BguxNcXj-QYtPaRQMiybNeg@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?  ("Graeme B. Bell" <graeme.bell@nibio.no>)
Список pgsql-performance
On Thu, Jul 9, 2015 at 4:44 AM, Graeme B. Bell <graeme.bell@nibio.no> wrote:
> On 09 Jul 2015, at 05:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> If you
>> write your is_prime function purely in plpgsql, and don't bother to mark
>> it nonvolatile, *it will not scale*.
>
>> much for properly written plpgsql; but there's an awful lot of bad plpgsql
>> code out there, and it can make a huge difference for that.
>
>
> Hi Tom,
>
> I object to phrases like 'don't bother to mark it' and 'bad plpgsql' here. That is putting the blame on programmers.
Clearly,if there is no end of code out there that isn't right in this regard, there's something very wrong in the
projectdocumentation. 
>
> 1. I have been writing pl/pgsql on and off for a couple of years now and I've read quite a bit of the postgres
doumentation,but I don't recall seeing a clear statement telling me I should mark pl/pgsql functions nonvolatile
whereverpossible or throw all performance and scalability out the window. I'm sure there may be a line hidden somewhere
inthe docs, but judging from the impact it has in practice, this seems like a very fundamental concept that should be
repeatedlyand clearly marked in the docs. 
>
> 2. Furthermore, I have never come across anything in the documentation that made it clear to me that any pl/pgsql
functionI write will, by default, be taking out locks for every single statement in the code. I've written code in I
dunno,maybe 15-20 different languages in my life, and I can't think of another language offhand that does that by
default.From the reactions on this thread to this benchmark and the par_psql benchmarks, it doesn't seem that it was
evenimmediately obvious to many postgres enthusiasts and developers. 
>
> 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.

merlin


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

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
Следующее
От: Thomas Kellerer
Дата:
Сообщение: Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?