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 1syqcU-002bLd-Ue for pgsql-bugs@arkaria.postgresql.org; Thu, 10 Oct 2024 10:42:12 +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 1syqbV-00FoLb-Lc for pgsql-bugs@arkaria.postgresql.org; Thu, 10 Oct 2024 10:41:10 +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 1syqbV-00FoK1-8S for pgsql-bugs@lists.postgresql.org; Thu, 10 Oct 2024 10:41:09 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1syqbR-000Bo7-Qc for pgsql-bugs@lists.postgresql.org; Thu, 10 Oct 2024 10:41:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1728556862; bh=gkGIen0XDoGzOUdwgjNW19mJmJi+Kd0iaFsJPPcISF0=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=i2mI6zlScoM6AgfO7NZEJW6FpIrny18Y/4uNjQXwzeAh5rLLAKM+sWXfJb2s9nJ6F iJyanqiMcvtJRBXC1nZSQnZEL+/7WOgiy51shxIebopmDtJEUKXsCcKW4rejy6j1dg D6XaTB71h/+e3w45CVZau/HnvK6YfxF40r8hWIuSDSUzmFFqcx4i4v4yBUxNVfuDOr 8t2AaZIFA2M3SbfOvMcvU0LAgN2uqw+Oa2V9n/TWsqudPE5UFpnF0bJchGWUNaNg8a s0HDMeJC2aNyxcna8jbnE6o9apDLtsHVv0SfK0goRwyKRonchsMhQDByZxD+to87Hk OrvdXIaXnd0uQ== Received: from [10.4.9.144] (unknown [93.174.131.141]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: a.rybakina@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id CF8F26018A; Thu, 10 Oct 2024 13:41:01 +0300 (MSK) Message-ID: Date: Thu, 10 Oct 2024 13:41:01 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index To: Andrei Lepikhov , Tender Wang Cc: Richard Guo , exclusion@gmail.com, pgsql-bugs@lists.postgresql.org, Tom Lane References: <18652-deaa782ebcca85d1@postgresql.org> <2527690.1728510183@sss.pgh.pa.us> <8026fe90-e661-4448-b9cc-bcbb65629b7b@gmail.com> Content-Language: en-US From: Alena Rybakina In-Reply-To: <8026fe90-e661-4448-b9cc-bcbb65629b7b@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-KSMG-AntiPhishing: NotDetected, bases: 2024/10/10 08:57:00 X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.1.0.7854, bases: 2024/10/10 09:24:00 #26730447 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 10.10.2024 13:23, Andrei Lepikhov wrote: > On 10/10/24 16:02, Tender Wang wrote: >> >> >> Andrei Lepikhov > 于2024年 >>      > I think this is because find_computable_ec_member() only tries to >>      > match Vars.  Maybe we should teach it to also match OpExprs? >>     Looking into that case, I don't understand only one thing: >>     generate_orderedappend_paths decided to try MergeAppend; the >>     create_append_path routine added the Sort cost,  but the Sort node >>     itself wasn't added. Maybe the origin problem is the lack of >>     feasibility >>     examinations? >> >> >> Yeah, I'm also curious why only cost Sort but not adding Sort node in >> create_merge_append_path(). >> The comments say that " We'll need to insert a Sort node, so include >> cost for that".  Does another place >> insert the Sort node? > Before inserting the Sort node, we must identify the column > corresponding to each path key. And here is the problem: IndexScan has > two elements in the target list, but SeqScan has only one. It already > looks strange to me. How do we UNION two sources with different > numbers of resulting columns? It seems to me we have a bug under the > Append node. > Maybe a mistake exists at the stage of creating a sequential scan? Because the subpath of the MergeAppend path does not have any elements in pathkeys, although the pasthtarget has one element and this expression wasn't involved anywhere? I honestly don’t understand at what stage this expression i+1 appears: SELECT i + 0 AS c FROM (SELECT i FROM t UNION ALL SELECT i + 1 FROM t) -- Regards, Alena Rybakina Postgres Professional