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 1s9tLM-005opJ-0L for pgsql-hackers@arkaria.postgresql.org; Wed, 22 May 2024 21:17:53 +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 1s9tLL-003tWL-Vx for pgsql-hackers@arkaria.postgresql.org; Wed, 22 May 2024 21:17:51 +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 1s9tLL-003tWC-MQ for pgsql-hackers@lists.postgresql.org; Wed, 22 May 2024 21:17:51 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s9tLJ-001Vsx-8x for pgsql-hackers@lists.postgresql.org; Wed, 22 May 2024 21:17:50 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 44MLHmxL019450; Wed, 22 May 2024 17:17:48 -0400 From: Tom Lane To: "a.rybakina" cc: PostgreSQL Developers Subject: Re: Sort operation displays more tuples than it contains its subnode In-reply-to: <9f4a159b-f527-465f-b82e-38b4b7df812f@postgrespro.ru> References: <9f4a159b-f527-465f-b82e-38b4b7df812f@postgrespro.ru> Comments: In-reply-to "a.rybakina" message dated "Wed, 22 May 2024 23:31:21 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <19448.1716412668.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Wed, 22 May 2024 17:17:48 -0400 Message-ID: <19449.1716412668@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "a.rybakina" writes: > I faced the issue, when the sorting node in the actual information  > shows a larger number of tuples than it actually is. And I can not > understand why? If I'm reading this correctly, the sort node you're worrying about feeds the inner side of a merge join. Merge join will rewind its inner side to the start of the current group of equal-keyed tuples whenever it sees that the next outer tuple must also be joined to that group. Since what EXPLAIN is counting is the number of tuples returned from the node, that causes it to double-count those tuples. The more duplicate-keyed tuples on the outer side, the bigger the effect. You can see the same thing happening at the Materialize a little further up, which is feeding the inside of the other merge join. regards, tom lane