From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | "Hartman, Matthew" <Matthew(dot)Hartman(at)krcc(dot)on(dot)ca>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Utilizing multiple cores in a function call. |
Date: | 2009-06-30 05:54:41 |
Message-ID: | 1246341281.22426.73.camel@tillium.localnet |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, 2009-06-29 at 14:42 -0400, Greg Smith wrote:
> -Write a "worker server" that you prompt to pick up work from a table and
> write its output to another that you can ask to handle part of the job.
> You might communicate with the worker using the LISTEN/NOTIFY mechanism in
> the database.
>
> -Some combination of these two techniques. One popular way to speed up
> things that are running slowly is to run some part of them in a C UDF, so
> that you could use "select my_big_computation(x,y,z)" and get faster
> execution.
The trouble here is that the backend may not like having threads
suddenly introduced into its execution environment.
If properly written, I don't really see why a C UDF that used pthreads
couldn't spawn two worker threads that _NEVER_ touched _ANY_ PostgreSQL
APIs, talked to the SPI, etc, and let them run while blocking the main
thread until they complete.
Then again, I know relatively little about Pg's guts, and for all I know
initing the pthread environment could completely mess up the backend.
Personally I'd want to do it out-of-process, using a SECURITY DEFINER
PL/PgSQL function owned by a role that also owned some otherwise private
queue and result tables for your worker server. As Greg Smith noted,
LISTEN/NOTIFY would allow your worker server to avoid polling and
instead sleep when there's nothing in the queue, and would also let your
waiting clients avoid polling the result table.
> For example, I've seen >10:1 speedups just be rewriting one small portion
> of a computationally expensive mathematical function in C before, keeping
> the rest of the logic on the database side. You don't necessarily have to
> rewrite the whole thing.
A useful dirty trick is to use Psyco in Python. It's a specializing
compiler that can get massive performance boosts out of Python code
without any code changes, and it seems to work with PL/Python. Just:
try:
import psyco
psyco.full()
except:
# Enabing Pysco failed; don't care
pass
in your function should get you a pretty serious boost. This will NOT,
however, allow your code to use two cores at once; you'll need threading
or multiple processes for that.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | valgog | 2009-06-30 08:46:31 | Re: Terrible Write Performance of a Stored Procedure |
Previous Message | Mike Ivanov | 2009-06-29 23:26:30 | Re: random slow query |