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 1rQM3Z-000ecf-O7 for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jan 2024 06:39:18 +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 1rQM3Y-000omu-L2 for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jan 2024 06:39:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rQM3Y-000omm-AB for pgsql-hackers@lists.postgresql.org; Thu, 18 Jan 2024 06:39:16 +0000 Received: from my.malkut.net ([138.201.153.82]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rQM3V-002Q57-81 for pgsql-hackers@postgresql.org; Thu, 18 Jan 2024 06:39:15 +0000 Received: (Haraka outbound); Thu, 18 Jan 2024 06:39:11 +0000 Authentication-Results: my.malkut.net; auth=pass (plain); spf=softfail smtp.mailfrom=malkut.net Received-SPF: SoftFail (my.malkut.net: domain of malkut.net does not designate 89.247.174.62 as permitted sender) receiver=my.malkut.net; identity=mailfrom; client-ip=89.247.174.62 helo=[192.168.7.153]; envelope-from= Received: from [192.168.7.153] (i59F7AE3E.versanet.de [89.247.174.62]) by my.malkut.net (Haraka/3.0.1) with ESMTPSA id 6458EA35-1E21-4893-9AD8-712ECBE463B5.1 envelope-from tls TLS_AES_256_GCM_SHA384 (authenticated bits=0); Thu, 18 Jan 2024 06:39:11 +0000 Message-ID: <542c1950-2bea-4fc2-911c-b18c0ec5d62b@malkut.net> Date: Thu, 18 Jan 2024 07:39:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: A performance issue with Memoize Content-Language: en-US To: Richard Guo , Andrei Lepikhov Cc: PostgreSQL-development References: <1d55df6d-92cb-4bbd-9a4c-0d05bb6bc91d@postgrespro.ru> From: Arne Roland In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=malkut.net; s=cloudron; h=from:subject:date:message-id:to:cc:mime-version; bh=EUMqBQS2fYny66S/2EBCpJzgAcdH5N7DAEsmN09tXNk=; b=gNQFkW2sLCwA2VmmvMSntGgczEq1rmSMD/HpA+f+WIFNfzR0KIxHGjiMhvXOnLsaGBiruwX2U2 nPsHsdEH2jOcCE1e5mVu7YK9aVhSe6BJowwzsP3bXIY/HGoWfuURzCjTBBEWTEr7xcybv8xcuE6T EP26QGsOeNRifLkJQSems= List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Richard, I can tell this a real world problem. I have seen this multiple times in production. The fix seems surprisingly simple. I hope my questions here aren't completely off. I still struggle to think about the implications. I wonder, if there is any stuff we are breaking by bluntly forgetting about the subplan params. Maybe some table valued function scan within a subquery scan? Or something about casts on a join condition, that could be performed differently? I wasn't able to construct a problem case. I might be just missing context here. But I am not yet fully convinced whether this is safe to do in all cases. Regards Arne