Re: any experience with multithreaded pg apps? - Mailing list pgsql-general

From Bill Moran
Subject Re: any experience with multithreaded pg apps?
Date
Msg-id 409BC916.1040300@potentialtech.com
Whole thread Raw
In response to any experience with multithreaded pg apps?  (Mark Harrison <mh@pixar.com>)
Responses Re: any experience with multithreaded pg apps?
List pgsql-general
Mark Harrison wrote:
> I'm looking for feedback from anybody who has used pg in a
> multi-threaded program, particularly one in which several
> threads each open a database connection.
>
> It's documented to work in that scenario, but I'm interested
> in anybody who can share some real-world with that.

I've done some real-world work like this.

The application is a SOAP server written in C using the gsoap library to
query a PostgreSQL database.  The nature of the server is that individual
queries are very fast (generally less than .1 sec) and the possibility of
multiple queries in rapid succession is likely.  The possibility of multiple
simultaneious queries also exists, but is unlikely.

I built the app thusly:
The bugger fires up and opens a connection to Postgres, and a listening
socket.  A thread mutex is used to get exclusive access to the Postgres
database connection.  When a connection arrives, an attempt is made to
lock the mutex, if it succeeds, a thread is fired off to handle that
connection and the loop returns to wait for additional connections.  When
the handling of the connection is complete, the mutex is released and the
thread ends.
If a new connection arrives and the mutex is already held by a previous
thread, a new connection is established and a flag is set to alert the
thread that it should close the connection to Postgres apon completion.
When the thread completes, it closes the connection instead of releasing
the mutex.

The results meet pretty much what we wanted:
1) Processing of a single connection is _very_ fast, since the connection
    To Postgres is already established, and the query and processing of the
    results occur very quickly.
2) The daemon _can_ handle multiple simultaneous connections.  Performance
    degrades a bit (in my tests, it's about half as fast when it has to
    establish a connection prior to the query).  Since the nature of the
    application lends itself more to rapid sequential queries from a single
    host than to multiple simultaneous queries, this is acceptable for us.

We've considered moving this to a pre-threaded model, but so far there hasn't
been a need, and there is other work to do :)  I do have another SOAP app that
does pre-forking and pre-establishes database connections, but that's not
threaded so it doesn't really apply to your question.

Reliability and performance have been good in this application.  Haven't had a
lick of trouble with Postgres or the client libraries.  We developed this
initially on 7.3, and it now runs on 7.4.

Hope this helps.

--
Bill Moran
Potential Technologies
http://www.potentialtech.com

pgsql-general by date:

Previous
From: Eduardo Pérez Ureta
Date:
Subject: Storing a file hash as primary key
Next
From: "Ed L."
Date:
Subject: Re: Interpreting vacuum verbosity