On 2015-07-08 23:38:38 -0400, Tom Lane wrote: > andres@xxxxxxxxxxx (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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
