From: | Tom Mercha <mercha_t(at)hotmail(dot)com> |
---|---|
To: | "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, "qiuxiafei(at)gmail(dot)com" <qiuxiafei(at)gmail(dot)com> |
Subject: | Re: Is is safe to use SPI in multiple threads? |
Date: | 2020-02-18 19:07:44 |
Message-ID: | DB7PR05MB50832F2AD5AF0525F5A7141BF4110@DB7PR05MB5083.eurprd05.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Nagaraj Raj | 2020-02-18 19:10:20 | Re: DB running out of memory issues after upgrade |
Previous Message | John W Higgins | 2020-02-18 18:51:46 | Re: How to handle CASE statement with PostgreSQL without need for typecasting |