Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mXYRR-0004oe-Pl for pgsql-bugs@arkaria.postgresql.org; Tue, 05 Oct 2021 00:36:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mXYRQ-0000Gk-JT for pgsql-bugs@arkaria.postgresql.org; Tue, 05 Oct 2021 00:36:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mXYRQ-0000Gc-9g for pgsql-bugs@lists.postgresql.org; Tue, 05 Oct 2021 00:36:20 +0000 Received: from mail-vs1-xe30.google.com ([2607:f8b0:4864:20::e30]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mXYRJ-0004ka-SH for pgsql-bugs@lists.postgresql.org; Tue, 05 Oct 2021 00:36:19 +0000 Received: by mail-vs1-xe30.google.com with SMTP id 188so21848469vsv.0 for ; Mon, 04 Oct 2021 17:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=lDIisPQBnUZwLi0aoBoK2CXr5Szd5g+7qEjIOw6iUyM=; b=jQnWn2xatvUR3/5Y4NZQbmTPeemTd4xzoxAGhd+vxgIUiXGo4YlsZzaMJvfWybZ6hF fcDdadY1en8BnsN9/jtlPWsg9htsc8+Y/rSgEhTm1ndqX5kdq6uzGiwlkGrsTbk+px0s 4XD/SB+yKs+iByrKVM1lysy1FXU1unJRqq7Ubc4VaCF30zx4rCIXe4DrlAr561zNHVkt Rj3cG96UiY0T4kPWFtNEEaEhZsvcdF4f1nA+Lld01LgRXabt3kHArX0Cq8/pR/WbtDWF pzxc6n7/KjR1hv/PJElRqK09ythEtOV2x9UaotUVYvRI7bW/5y2ICWciipDEQrmZowk3 G4tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=lDIisPQBnUZwLi0aoBoK2CXr5Szd5g+7qEjIOw6iUyM=; b=VjCYtWTWHwx24VJaFYBHOUJZIYT+pm5JoD9mJ98Y+tudgBc2JsuycUZsUeR4DNzzpm f6OwF8jBEvtscYidCCxLpwpNAGEb8V8xbiGgt7HJ0zaYtkCHFmzJZXGG/RkjB9VBpKLV +YdtF16mBiBLKG1iW5mK1UG0W921xEPfJe3WVvi11bBpQzhQQx8Khk6D8nAV7CTLCQmO saTcJJvbs23bWdnBwGKBMIp+Ol3sS0Qrc8EWn6GerC8mLXsgyMPmcAKjDspOW1nLMbRw mG/UPSk9STVpKHNMBTAsK1kz87J49pDezDeujBCr7U+FT9Ht8ZZTqJjyHgzaRbeUqfJc XEUA== X-Gm-Message-State: AOAM530m3NJnMwNPaveQ0xZ403z2uC0XHFO3S5IXlADGQWxQ6IV+fZ2G hBenh9duELSftBor5a6eRh/rAiaJSgF6Sg== X-Google-Smtp-Source: ABdhPJxot1qSn3Q/kRK+ORko3WdDUayB4AEC90DS9vq0Bjb0r5Ora7IrVAiEEBQQJpoWbAXLWh2LhQ== X-Received: by 2002:a05:6102:ec3:: with SMTP id m3mr16295282vst.0.1633394171808; Mon, 04 Oct 2021 17:36:11 -0700 (PDT) Received: from vulcan.edgedb.net (c-73-70-233-86.hsd1.ca.comcast.net. [73.70.233.86]) by smtp.gmail.com with ESMTPSA id i19sm1606857uap.12.2021.10.04.17.36.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Oct 2021 17:36:11 -0700 (PDT) From: Elvis Pranskevichus To: PostgreSQL mailing lists , David Rowley Subject: Re: BUG #17213: Wrong result from a query involving Merge Semi Join and Memoize Date: Mon, 04 Oct 2021 17:36:09 -0700 Message-ID: <4374396.LvFx2qVVIh@vulcan.edgedb.net> In-Reply-To: References: <17213-988ed34b225a2862@postgresql.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Monday, October 4, 2021 5:14:47 PM PDT David Rowley wrote: > On Tue, 5 Oct 2021 at 12:22, PG Bug reporting form > > wrote: > > It appears a combination of Merge Semi Join and Memoize in > > PostgreSQL 14 produces incorrect results on a particular query. > > The bug might be present > > in earlier versions, but I was only able to reproduce a particular > > plan under version 14. > > Are you able to send the output of EXPLAIN (ANALYZE, SETTINGS) from > the problem query with SET enable_memoize = ON; ? My local setup here > does not produce the same plan as you're getting and that might be > because you have some non-standard cost settings. > > It does look a bit like memoize is not properly taking into account > the fact that there's a subplan below the memoize node with parameters > from above the memoize node. Namely the i1.id in issue_id != i1.id. All cost and planner settings are set to defaults on the cluster I'm getting this plan on (only `search_path` shows up in SETTINGS). It seems like a very particular set of stats is causing the plan there, as running ANALYZE turns the query into a Nested Loop Semi Join. Elvis