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 1sBDnY-00FAdJ-Ry for pgsql-general@arkaria.postgresql.org; Sun, 26 May 2024 13:20:30 +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 1sBDnX-0043j3-EX for pgsql-general@arkaria.postgresql.org; Sun, 26 May 2024 13:20:27 +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 1sBDnX-0043iu-0q for pgsql-general@lists.postgresql.org; Sun, 26 May 2024 13:20:27 +0000 Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sBDnS-0024l5-QB for pgsql-general@lists.postgresql.org; Sun, 26 May 2024 13:20:25 +0000 Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-6f8eba8f25eso1913139b3a.3 for ; Sun, 26 May 2024 06:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716729622; x=1717334422; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=mngqX2d3ngSxE2ZVJMxPaPr+wtrtf14TklV8kQiHcHQ=; b=ao3KhyokZ3KF6cWcfVzq9m+uWDf70uz/Kqu7VHWu5AGhr4uaa2x3ZgvkvVKarZ5R3p p4SZblSOz9F8bQ8DfFgpdoTzPc+wOHO/AoSPz5YtJUJRWMEXXXS2kFAV+POvUU3cojl3 VfpKUVnfQCHoVPskvTRTmmJ7QYxLMKARo3ShF7C/AnwqR/RUXaaTEVeYVf5eyWC/g16h aO8azacHRj3BOU2/YyTC+eU0sgyrD44JSj8yo3sI6wVDI9BHxF+Ai1y4lQB4MkIL+48G 6ZCbnA3Z8PSUOGtNQY9ZJmtemtcN3otTOUCLmz2RgBrw4+t+IQhkifqclhT05W0xBSJ8 OhYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716729622; x=1717334422; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=mngqX2d3ngSxE2ZVJMxPaPr+wtrtf14TklV8kQiHcHQ=; b=KlsUR1MkcgUFb2lLVovugbTZb5G4UZ65TPecv52zfF4TUxj2jEeLxKutBznO0BEDIi 3JOPwhzRgKfc7hsuo6RcbobUXjL2A27mkXLXsFFYRIfw8Q4NnSuglmar9y8UAL2sfJNN ae72uPS+AMCMvU0PnjSZDI9c7wAcPQJwjsoRbDOCBziiPVSOhvQJaGdjpd15H6l4kQWz lSILFek5kWr98ErKejE5tAsKtCjbDsxW1T8wHv+MuDjjDpgKYhUsrP4uD6EO8ztYhvnm P+V7bvn9rqH2BuEhnRdLKBeTdegg0Xd5mzmZhBXcUriyy4mR49r6aC2VcZihjd7EtZSP NSsA== X-Gm-Message-State: AOJu0YyM7/uGt8I7B+B1iI+2OA5+ZMekp0CxwxVTx4Uo/lDn0FvSt2nb hH2v+otxJLq1QWqBbbkQn8EPd8c3GISLzfUdBC5pahSD/mk1J0IMMOu0zP36+lj2A+RtBkEicYT LA6HJBqLKYFpah9ZeX2IDutwg8+Wpok0Q X-Google-Smtp-Source: AGHT+IEObwRlf8CfpdeG5swaGdbQAW7P+YrmK7omuP6686iZC3TH/hcMTTf8Y+O3K95zd3p+3Xpx6jBJAsngnNPHaqg= X-Received: by 2002:a05:6a20:3c9f:b0:1b0:225:2b27 with SMTP id adf61e73a8af0-1b212f5eee0mr7373726637.51.1716729621444; Sun, 26 May 2024 06:20:21 -0700 (PDT) MIME-Version: 1.0 From: Victor Dobrovolsky Date: Sun, 26 May 2024 16:20:10 +0300 Message-ID: Subject: scalar plpgsql functions and their stability flags To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000042fef306195b439f" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000042fef306195b439f Content-Type: text/plain; charset="UTF-8" Good day experts... Question on scalar plpgsql functions stability flags (immutable, stable) regarding how it works in sql queries. It is clear that for immutable/stable functions with constant parameters, query planner could/should calculate value in a parse time and use it directly in query, or at least once per query. But it is unclear for me what exactly should/can happens when parameters are bounded not to constant values but to query fields. In such a case there could be some caching mechanics involved for parameters combinations and result values. Like building a hash table for that or something similar. Can someone give me guidance on this matter. What limits the usefulness of such a mechanism, if it exists. Thank you. --00000000000042fef306195b439f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good day experts...

Question on scalar plpgsql func= tions stability flags (immutable, stable) regarding how it works in sql que= ries.

It is clear that for immutable/stable functions with constant = parameters,
=C2=A0query planner could/should calculate value in a parse = time and use it directly in query, or at least once per query.

But i= t is unclear for me what exactly should/can happens when parameters are bou= nded not to constant values but to query fields.
In such a case there co= uld be some caching mechanics involved for parameters combinations and resu= lt values.
Like building a hash table for that or something similar.
=
Can someone give me guidance on this matter.
What limits the usefuln= ess of such a mechanism, if it exists.

Thank you.=C2=A0

=
--00000000000042fef306195b439f--