public inbox for [email protected]
help / color / mirror / Atom feedRe: can stored procedures with computational sql queries improve API performance?
2+ messages / 2 participants
[nested] [flat]
* Re: can stored procedures with computational sql queries improve API performance?
@ 2024-07-10 20:17 Ron Johnson <[email protected]>
2024-07-10 20:37 ` Re: can stored procedures with computational sql queries improve API performance? Juan Rodrigo Alejandro Burgos Mella <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Ron Johnson @ 2024-07-10 20:17 UTC (permalink / raw)
To: pgsql-general
On Tue, Jul 9, 2024 at 8:58 PM Krishnakant Mane <[email protected]> wrote:
> Hello.
>
> I have a straight forward question, but I am just trying to analyze the
> specifics.
>
> So I have a set of queries depending on each other in a sequence to
> compute some results for generating financial report.
>
> It involves summing up some amounts from tuns or of rows and also on
> certain conditions it categorizes the amounts into types (aka Debit
> Balance, Credit balance etc).
>
> There are at least 6 queries in this sequence and apart from 4 input
> parameters. these queries never change.
>
> So will I get any performance benefit by having them in a stored
> procedure rather than sending the queries from my Python based API?
One problem is that the query planner reverts to a generic query plan if
you execute the same query over and over in a loop in the SP.
That bit us once. A big SP that had been running "normally" for months
suddenly went from about 20 minutes to six hours. The solution (given by
someone on this list a couple of years ago) was to add "set plan_cache_mode
= force_custom_plan;" above the call.
That way, the query plan was updated every time. Performance dropped to
about 8 minutes IIRC.
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: can stored procedures with computational sql queries improve API performance?
2024-07-10 20:17 Re: can stored procedures with computational sql queries improve API performance? Ron Johnson <[email protected]>
@ 2024-07-10 20:37 ` Juan Rodrigo Alejandro Burgos Mella <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Juan Rodrigo Alejandro Burgos Mella @ 2024-07-10 20:37 UTC (permalink / raw)
To: Ron Johnson <[email protected]>; +Cc: pgsql-general
Great tip!!! Thx
El mié, 10 de jul de 2024, 16:17, Ron Johnson <[email protected]>
escribió:
> On Tue, Jul 9, 2024 at 8:58 PM Krishnakant Mane <[email protected]>
> wrote:
>
>> Hello.
>>
>> I have a straight forward question, but I am just trying to analyze the
>> specifics.
>>
>> So I have a set of queries depending on each other in a sequence to
>> compute some results for generating financial report.
>>
>> It involves summing up some amounts from tuns or of rows and also on
>> certain conditions it categorizes the amounts into types (aka Debit
>> Balance, Credit balance etc).
>>
>> There are at least 6 queries in this sequence and apart from 4 input
>> parameters. these queries never change.
>>
>> So will I get any performance benefit by having them in a stored
>> procedure rather than sending the queries from my Python based API?
>
>
> One problem is that the query planner reverts to a generic query plan if
> you execute the same query over and over in a loop in the SP.
>
> That bit us once. A big SP that had been running "normally" for months
> suddenly went from about 20 minutes to six hours. The solution (given by
> someone on this list a couple of years ago) was to add "set plan_cache_mode
> = force_custom_plan;" above the call.
>
> That way, the query plan was updated every time. Performance dropped to
> about 8 minutes IIRC.
>
>
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-07-10 20:37 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-07-10 20:17 Re: can stored procedures with computational sql queries improve API performance? Ron Johnson <[email protected]>
2024-07-10 20:37 ` Juan Rodrigo Alejandro Burgos Mella <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox