From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Craig James <cjames@emolecules.com>
Cc: Merlin Moncure <mmoncure@gmail.com>
Cc: Joshua D. Drake <jd@commandprompt.com>
Cc: Graeme B. Bell <graeme.bell@nibio.no>
Cc: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
Date: Thu, 9 Jul 2015 11:00:08 +0200
Message-ID: <20150709090008.GV10242@alap3.anarazel.de> (raw)
In-Reply-To: <15702.1436413118@sss.pgh.pa.us>
References: <6E55113B-FA05-433C-9B21-623F798EE935@skogoglandskap.no>
<CAFwQ8rcEOiGJ79WtoO=uTX33ZhKVUWG9v8iO14TR+AoT_wd1og@mail.gmail.com>
<559CB5BF.2080509@commandprompt.com>
<CAFwQ8rdWcZwUxgQDySOzFAqHJPm6=DVH+bp0XMJzmADF1GVmPw@mail.gmail.com>
<CAHyXU0wO_WMzrbdcdtWwpk-78j_4P-M-Kr0xOyJVg1K15dQNAQ@mail.gmail.com>
<20150708202733.GS10242@alap3.anarazel.de>
<CAFwQ8rcmN5APWKS8v9JBqvQ8_x2by276LFBZxtci-32BnuMGUg@mail.gmail.com>
<20150708224518.GT10242@alap3.anarazel.de>
<15702.1436413118@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
On 2015-07-08 23:38:38 -0400, Tom Lane wrote:
> andres@anarazel.de (Andres Freund) writes:
> > On 2015-07-08 15:38:24 -0700, Craig James wrote:
> >> From my admittedly naive point of view, it's hard to see why any of this
> >> matters. I have functions that do purely CPU-intensive mathematical
> >> calculations ... you could imagine something like is_prime(N) that
> >> determines if N is a prime number. I have eight clients that connect to
> >> eight backends. Each client issues an SQL command like, "select
> >> is_prime(N)" where N is a simple number.
>
> > I mostly replied to Merlin's general point (additionally in the context of
> > plpgsql).
>
> > But I have a hard time seing that postgres would be the bottleneck for a
> > is_prime() function (or something with similar characteristics) that's
> > written in C where the average runtime is more than, say, a couple
> > thousand cyles. I'd like to see a profile of that.
>
> But that was not the case that Graeme was complaining about.
No, Craig was complaining about that case...
> One of my Salesforce colleagues has been looking into ways that we could
> decide to skip the per-statement snapshot acquisition even in volatile
> functions, if we could be sure that a particular statement isn't going to
> do anything that would need a snapshot.
Yea, I actually commented about that on IRC as well.
I was thinking about actually continuing to get a snapshot, but mark it
as 'complete on usage'. I.e. only call GetSnapshotData() only when the
snapshot is used to decide about visibility. We probably can't do that
in the toplevel visibility case because it'll probably have noticeable
semantic effects, but ISTM it should be doable for the volatile function
using spi case.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: andres@anarazel.de, tgl@sss.pgh.pa.us, cjames@emolecules.com, mmoncure@gmail.com, jd@commandprompt.com, graeme.bell@nibio.no
Subject: Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
In-Reply-To: <20150709090008.GV10242@alap3.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox