Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sRdl4-00HIzC-06 for pgsql-general@arkaria.postgresql.org; Wed, 10 Jul 2024 20:17:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sRdl2-008hWR-DX for pgsql-general@arkaria.postgresql.org; Wed, 10 Jul 2024 20:17:44 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sRdl2-008hVI-1y for pgsql-general@lists.postgresql.org; Wed, 10 Jul 2024 20:17:44 +0000 Received: from mail-oo1-xc30.google.com ([2607:f8b0:4864:20::c30]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sRdkz-001QTG-FJ for pgsql-general@postgresql.org; Wed, 10 Jul 2024 20:17:42 +0000 Received: by mail-oo1-xc30.google.com with SMTP id 006d021491bc7-5c47ad9967cso90600eaf.2 for ; Wed, 10 Jul 2024 13:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720642660; x=1721247460; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=x1jwxiZ9JNwXQJJoEZ/dsZpQncZ2ZLbk7B1ZdnacHt0=; b=aM8cHuBC1jzzZC5jxEYILmhX1Ck5zwD71bbFtFCx7e5olU5rNsLBvUghCcd+hqlDz8 7DUoozkVuued6OviU6FXzlUeZBfSY1JEvASGPtBeoMmNppmkRxtJUyGTjn47Hx7p8Rqk hron2wxnEOaUnKUVht0L2sFoUvkFsLGIas4J4q2MXpuKSikcJzNtIJts1j6lgQSCBdi/ Ccs9Jp9/s0htQYK64238/IP4gGcP5AN0h06THP4/5VOybN0HwGYjqovvg6cM124qx3uz 4kW4XsYfjQ8tHtEQodkYYYQlUN0tsydSsneOhW1S8hc1g3jTVPx1BK6p8I8C0JRIHOQ2 19OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720642660; x=1721247460; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=x1jwxiZ9JNwXQJJoEZ/dsZpQncZ2ZLbk7B1ZdnacHt0=; b=rnzqZZL+yTkzSw1KgazeaCGuxMe1pMvtqWdNm2XBazvHMxKWARlpwRggIjrN5U177s OFpkZuYqEms+BCrJML80RTnzHyB24D/nQ6kPvGIbzchpboVnOMDWxbQsAROhkiIC5gr7 2Q686J+kJzzvQA6/vbrdj7+tWq1HFThgeNSzLZD9VoiNBYytVOf9jtEh1jxkG1XYgTgo 5DNgX/AVOPOVpYJ6VcEpo/3BycmIf7rr6xT5/uJN7cN0AJ3XnpjeMNioCFCm4Ns6N6im yY/VKebUSZ3pmA+HGVBu/k1DZTlqa7bSAoD74Of0oZEH0aYzZLGfh3DypQzAM0ucHcwj vS/A== X-Gm-Message-State: AOJu0Yzz/1YrNuPPU6xF70MBEeKIlrb6r+yTINQFMGvutPzX1VDsovb8 1zXO7EAcrQB8EmsIRugpWfKo/pu4namd51bSUUdQkNVkMVl9XJCj/vx6QcLfZdy6kM23HpKaBb7 dTGz16MtGSVj27UvPSewF5Kzz6w4LkaD6 X-Google-Smtp-Source: AGHT+IHYdM2wHbDTsyB87T6WcN54f1Tty5PmZBmAOXt/UabkAcW2j8OmUCiCjsgyHDBEtdGH5DuwCmrSUeUUpOvZsq0= X-Received: by 2002:a05:6871:6a93:b0:25e:1382:8653 with SMTP id 586e51a60fabf-25eaebd50d8mr4076897fac.43.1720642660415; Wed, 10 Jul 2024 13:17:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Wed, 10 Jul 2024 16:17:28 -0400 Message-ID: Subject: Re: can stored procedures with computational sql queries improve API performance? To: pgsql-general Content-Type: multipart/alternative; boundary="0000000000008f4572061cea5663" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000008f4572061cea5663 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 9, 2024 at 8:58=E2=80=AFPM Krishnakant Mane 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 =3D force_custom_plan;" above the call. That way, the query plan was updated every time. Performance dropped to about 8 minutes IIRC. --0000000000008f4572061cea5663 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 9, 2024 at 8:58=E2=80=AFPM Kr= ishnakant Mane <kkproghub@gmail.c= om> 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 i= n the SP.

That bit us once.=C2=A0 A big SP that ha= d been running "normally" for months suddenly went from about 20 = minutes to six hours.=C2=A0 The solution (given by someone on this list a c= ouple of years ago) was to add "set plan_cache_mode =3D force_custom_p= lan;" above the call.

That way, the query pla= n was updated every time.=C2=A0 Performance dropped to about 8 minutes IIRC= .

--0000000000008f4572061cea5663--