Andy Halsall <halsall_andy@xxxxxxxxxxx> writes: > I've written an Immutable stored procedure that takes no parameters and returns a fixed value to try and determine the round trip overhead of a query to PostgreSQL. Call to sp is made using libpq. We're all local and using UNIX domain sockets. > Client measures are suggesting ~150-200 microseconds to call sp and get the answer back That doesn't sound out of line for what you're doing, which appears to include parsing/planning a SELECT command. Some of that overhead could probably be avoided by using a prepared statement instead of a plain query. Or you could try using the "fast path" API (see libpq's PQfn) to invoke the function directly without any SQL query involved. Really, however, the way to make things fly is to get rid of the round trip overhead in the first place by migrating more of your application logic into the stored procedure. I realize that that might require pretty significant rewrites, but if you can't tolerate per-query overheads in the 100+ usec range, that's where you're going to end up. If you don't like any of those answers, maybe Postgres isn't the solution for you. You might consider an embeddable database such as SQLLite. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
