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 1qaGYF-008hJk-Oh for pgsql-novice@arkaria.postgresql.org; Sun, 27 Aug 2023 14:15:39 +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 1qaGYD-000S0c-JF for pgsql-novice@arkaria.postgresql.org; Sun, 27 Aug 2023 14:15:37 +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 1qaGYD-000S0U-7r for pgsql-novice@lists.postgresql.org; Sun, 27 Aug 2023 14:15:37 +0000 Received: from mail-oo1-xc2d.google.com ([2607:f8b0:4864:20::c2d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qaGY6-001F7e-Es for pgsql-novice@lists.postgresql.org; Sun, 27 Aug 2023 14:15:35 +0000 Received: by mail-oo1-xc2d.google.com with SMTP id 006d021491bc7-5738949f62cso121724eaf.0 for ; Sun, 27 Aug 2023 07:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693145729; x=1693750529; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GjqZ92Ocf0h5tch1aViLsmaO2+OSes4AQxg3DkxfFY4=; b=JAITJ5bX/FbzL9z6oH94Ow1ko3rJ+iIjUm7U/vbaLSV/PfDyNFnUuGgiEeJWJpv1gg 3AquBNFVyaeITWyLKGs8ICoSo2VjMtud3LcjTpdT4oy7JntxctNrz0g5HagJdKfusri2 1SRrts7jQteI2v7E+P5qNZa6U0slzCl0cjs8wQ9TfHYm5+5YxiAvs3r7pZ06aqy6JqZK d7BDhQOIgZLSeWuPJ377KVyT2bF7ZYqXURdMQE+s37qXaKwabKJsMiNgWjHWcKuMIno/ XlkYUubSUfbmYdldDSvOZKWQkyGXMsmJYBpTYsjYdMLErFym2KpFax3B8j3LSymeN/N+ 7EuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693145729; x=1693750529; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GjqZ92Ocf0h5tch1aViLsmaO2+OSes4AQxg3DkxfFY4=; b=Tmm3iw94A8pbDW7ZYTbPmI3LFo8lX08d/n0UXJRuhH3WdBWtZJLoG4zyl6YX+LhHDH 5yXhU1+0PKjgs3jCrFW+B2jhP5Jt2bALTwlaTuaBaOEYy9JFe5zxyR5Yym+wTPVkHSix yjmHkLcEh1bzESr6njtXYyCBVlqcJfgRgMBE9KMDshqs8t2OWhA2Nch/SXdcPYnUEO6D sg9qSXUCz/UaEv7fwOYGrEVipimILT2QPOHlrgwAD9WC0cOMZv9fewc828+2NigSI5Lr 2xNtO3fy0Vh+XkD7BTwncrfLj0DL4EywY/r3KIchl3hMitSp6IuCZJdDySZoKxu7NEGQ JT0g== X-Gm-Message-State: AOJu0Yzr0rrVbwrxUQr67QkisSZWAvvszkYpaVc59ECFCkZlDe88fJIL dhE0zYyy6ExoEpgt2mwxZ2jzDWyvxccIW1yvUByXa6Gk X-Google-Smtp-Source: AGHT+IHlGqaYsX6iE0MehM5W3DeKtuTAPs6lJd1oK4ML9/aI/mBaXy/lUS0eLaeTvc0ilnRpi2sHXFTLM+YSasEnCRk= X-Received: by 2002:a4a:6c1d:0:b0:571:1fad:ebdd with SMTP id q29-20020a4a6c1d000000b005711fadebddmr9275525ooc.1.1693145729379; Sun, 27 Aug 2023 07:15:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a8a:a9a:0:b0:4ea:3880:2f10 with HTTP; Sun, 27 Aug 2023 07:15:28 -0700 (PDT) In-Reply-To: References: From: "David G. Johnston" Date: Sun, 27 Aug 2023 07:15:28 -0700 Message-ID: Subject: Re: Stored procedures To: Simon Connah Cc: pgsql-novice Content-Type: multipart/alternative; boundary="000000000000c0b5790603e835fc" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c0b5790603e835fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sunday, August 27, 2023, Simon Connah wrote: > I'm building a website in Python using the Django framework and am using > the ORM at the moment but I can see a few situations where I might need t= o > write raw SQL. My question is do stored procedures execute faster when > compared to queries you generate using Python and then send to PostgreSQL= ? > I would assume they would as there is less communication between the two > sides and also because PostgreSQL knows the stored procedure ahead of tim= e > it should be able to better optimise it. > > Is that true? Does PostgreSQL use a JIT for stored procedures which make > them faster than one-off queries? Forget generalities. Do what makes the most overall sense. If a specific case seems to need performance optimization then do both and measure. If you are using plpgsql as the implementation language, or anything but the atomic SQL format actually, you aren=E2=80=99t avoiding the parsing of = the code and are adding overhead that raw SQL doesn=E2=80=99t have. David J. --000000000000c0b5790603e835fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sunday, August 27, 2023, Simon Connah <simon.n.connah@protonmail.com> wrote:
I'm building a website in Python using the Djang= o framework and am using the ORM at the moment but I can see a few situatio= ns where I might need to write raw SQL. My question is do stored procedures= execute faster when compared to queries you generate using Python and then= send to PostgreSQL? I would assume they would as there is less communicati= on between the two sides and also because PostgreSQL knows the stored proce= dure ahead of time it should be able to better optimise it.

Is that true? Does PostgreSQL use a JIT for stored procedures which make th= em faster than one-off queries?

Forget gene= ralities.=C2=A0 Do what makes the most overall sense.=C2=A0 If a specific c= ase seems to need performance optimization then do both and measure. =C2=A0=

If you are using plpgsql as the implementation la= nguage, or anything but the atomic SQL format actually, you aren=E2=80=99t = avoiding the parsing of the code and are adding overhead that raw SQL doesn= =E2=80=99t have.

David J.
--000000000000c0b5790603e835fc--