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 1v1USl-009CIe-8p for pgsql-bugs@arkaria.postgresql.org; Wed, 24 Sep 2025 18:43:35 +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 1v1USj-00F7id-Ju for pgsql-bugs@arkaria.postgresql.org; Wed, 24 Sep 2025 18:43:33 +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 1v1USj-00F7iU-8X for pgsql-bugs@lists.postgresql.org; Wed, 24 Sep 2025 18:43:33 +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.96) (envelope-from ) id 1v1USg-002EJQ-2p for pgsql-bugs@lists.postgresql.org; Wed, 24 Sep 2025 18:43:32 +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 58OIhTu03455130; Wed, 24 Sep 2025 14:43:29 -0400 From: Tom Lane To: lukas.eder@gmail.com cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #19063: Heavily nesting trivial ROW projections produces out of memory error In-reply-to: <19063-c1ba39b11b9d43b7@postgresql.org> References: <19063-c1ba39b11b9d43b7@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Wed, 24 Sep 2025 14:06:07 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3455127.1758739409.1@sss.pgh.pa.us> Date: Wed, 24 Sep 2025 14:43:29 -0400 Message-ID: <3455128.1758739409@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form writes: > I don't understand how such excessive memory consumption is produced by such > a "simple" query. Compare regression=# select row(row(1)); row --------- ("(1)") (1 row) regression=# select row(row(row(1))); row --------------- ("(""(1)"")") (1 row) regression=# select row(row(row(row(1)))); row ------------------------- ("(""(""""(1)"""")"")") (1 row) Each layer of ROW() has to quote the string representing the next lower layer, so it doubles all the double-quotes per the quoting rules at https://www.postgresql.org/docs/current/rowtypes.html#ROWTYPES-IO-SYNTAX So the output length nearly doubles for each layer of ROW(), and yes it doesn't take that many layers to get to something excessive. Maybe we could redefine the quoting rules in a way that's friendlier to this sort of thing, but it would surely make them a lot more complicated, which would likely introduce enough client-side bugs to make the change unattractive. Not to mention the whole backwards compatibility question. On the whole I can't get excited about this, since I see no very good reason to use such a data structure. regards, tom lane