Re: Is is safe to use SPI in multiple threads? - Mailing list pgsql-general

From Tom Mercha
Subject Re: Is is safe to use SPI in multiple threads?
Date
Msg-id DB7PR05MB50832F2AD5AF0525F5A7141BF4110@DB7PR05MB5083.eurprd05.prod.outlook.com
Whole thread Raw
In response to Re: [GENERAL] Is is safe to use SPI in multiple threads?  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
Responses Re: Is is safe to use SPI in multiple threads?
List pgsql-general
On 23/12/2016 13:41, Peter J. Holzer wrote:
> On 2016-12-09 16:52:05 +0800, Qiu Xiafei wrote:
>> I'm new to PG and want to implement my domain-specific system based on PG. I
>> wish to arrange my data as several tables in database and translate my DSL into
>> SQL statements for query. Since one DSL statement may be mapped to several SQL
>> statements, it's better to push the DSL server as close to the PG server as
>> possible. I found PG's backgroud worker meet my needs. I can setup a background
>> worker bounded to PG server and listen to a port for network requests.
>>
>> But I encounter a problem that the Server Programing Interfaces are not THREAD
>> SAFE. There are some global variables defined like: SPI_processed,
>> SPI_tuptable, etc. This limit to my DSL server to work in single thread mode
>> which is quite inefficient.
>
> I had a similar requirement. I solved it by moving the application logic
> out of the stored procedures. All the stored procedure does is an RPC
> call (I use ØMQ for that) to a server process and send the result back
> to the client. The server process converts the request into multiple SQL
> queries which can be processed in parallel.
>
> The downside is of course that the communication overhead is much
> higher (A minimum of 4 network messages per request). That's not a
> problem in my case, but you mileage may vary.
>
> The advantages in my opinion are:
>
> * A standalone server process is easier to test and debug than a bunch
>    of stored procedures.
> * I can easily scale out if necessary: Currently my database and server
>    process run on the same machine, but I could distribute them over
>    several machines with (almost) no change in logic.
>
>          hp
>

Sorry to revive such an old topic. I am facing a similar requirement
where I am running multiple queries concurrently. Like Qiu Xiafei, I am
looking at SPI, and dynamic background workers. In particular, I am
using SPI_execq(...) on each dynamic background workers I spawn. What I
am experiencing is that I am not seeing a speedup, and I am beginning to
wonder if I have done something wrong, if the overheads are too big, or
if there are some limitations I am not aware of.

As I see that none of the comments here make much of a reference to
performance/speedup, would you be so kind as to tell me how satisfied
you were with performance? Any insights would be greatly appreciated.

Thanks,
Tom



pgsql-general by date:

Previous
From: John W Higgins
Date:
Subject: Re: How to handle CASE statement with PostgreSQL without need for typecasting
Next
From: "Bellrose, Brian"
Date:
Subject: pglogical install errors openSUSE Leap 42.1