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 1u4Gtw-00A86P-7q for pgsql-general@arkaria.postgresql.org; Mon, 14 Apr 2025 10:18:52 +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 1u4Gtu-00Go7M-4r for pgsql-general@arkaria.postgresql.org; Mon, 14 Apr 2025 10:18:50 +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 1u4Gtt-00Go7D-Qs for pgsql-general@lists.postgresql.org; Mon, 14 Apr 2025 10:18:50 +0000 Received: from dd25110.kasserver.com ([85.13.146.49]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u4Gtr-000GSm-2k for pgsql-general@lists.postgresql.org; Mon, 14 Apr 2025 10:18:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technowledgy.de; s=kas202308201259; t=1744625924; bh=SQIgYW1VGOKOcg0sX36vMfHOZNVb1sLfMzk3l2xdC2w=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ugWQFu3JWztEfs+HN+MQHFkvAaobiCQfbriH9uXg4d7uC7H8iGtC6QfygyKPQSR0q 1KT7vZMWNdARwGjvakhbC5qC6n7OPA1Ip28uf4Zoc8augjhB1ebAD2/iwV4LIIntb7 LYh63Q/53xJVEpCU14QvA7jlFtN9X+JSA8t35G7rbubnBkR9uox5ZQ4JUTEcEpotOO oKEz162Thy8MLiY+DTWjg723UV+k1ZreqVkI3lh2wsGxXCvWz9x08+EZA9K5b1ooz4 Fa/bnJE/tXyZZeEd30JcF4R+Ahbnse/Fg2916ygCB/SF4N+3yhVjZmEDXst1LdRAfP uc2C2NFZDP60A== Received: from [192.168.0.102] (ip-037-201-153-223.um10.pools.vodafone-ip.de [37.201.153.223]) by dd25110.kasserver.com (Postfix) with ESMTPSA id 9035DE1A0223; Mon, 14 Apr 2025 12:18:44 +0200 (CEST) Message-ID: <4ea0957f-d599-47e5-ae9e-758ec6711e03@technowledgy.de> Date: Mon, 14 Apr 2025 12:18:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Interesting case of IMMUTABLE significantly hurting performance Content-Language: en-US To: Tom Lane , "David G. Johnston" Cc: Laurenz Albe , Olleg Samoylov , "pgsql-generallists.postgresql.org" References: <662101e2-5ca5-4bf5-9307-2519efde8690@ya.ru> <8687df7d49bc4b28b41c7cf4e9ad1e15d383b2fa.camel@cybertec.at> <373227.1744236488@sss.pgh.pa.us> From: Wolfgang Walther In-Reply-To: <373227.1744236488@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: + List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Tom Lane: > If you err in the other direction, you don't get slapped on the > wrist that way. We're willing to inline VOLATILE functions, > for instance, whether or not the contained expression is volatile. > Similarly for STRICT, and I think parallel safety as well. > So my own habit when writing a SQL function that I wish to be > inlined is to leave off all those markings. According to [1], this only applies to inlining of scalar functions, but not to table functions, which *need* to be either STABLE or IMMUTABLE. Just mentioning this for anyone taking this advice blindly and leaving all marks off, which might not always work as expected in the general case. Best, Wolfgang [1]: https://wiki.postgresql.org/wiki/Inlining_of_SQL_functions