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 1lmDOd-0000EM-JU for pgsql-performance@arkaria.postgresql.org; Thu, 27 May 2021 10:37:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lmDOc-0001KF-96 for pgsql-performance@arkaria.postgresql.org; Thu, 27 May 2021 10:37:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lmDOb-0001K0-SZ for pgsql-performance@lists.postgresql.org; Thu, 27 May 2021 10:37:46 +0000 Received: from forward100o.mail.yandex.net ([2a02:6b8:0:1a2d::600]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lmDOW-0000vy-Qp for pgsql-performance@postgresql.org; Thu, 27 May 2021 10:37:44 +0000 Received: from forward101q.mail.yandex.net (forward101q.mail.yandex.net [IPv6:2a02:6b8:c0e:4b:0:640:4012:bb98]) by forward100o.mail.yandex.net (Yandex) with ESMTP id 0761C4AC09FD for ; Thu, 27 May 2021 13:37:35 +0300 (MSK) Received: from vla1-af11d61edf22.qloud-c.yandex.net (vla1-af11d61edf22.qloud-c.yandex.net [IPv6:2a02:6b8:c0d:3902:0:640:af11:d61e]) by forward101q.mail.yandex.net (Yandex) with ESMTP id 0314ECF40053 for ; Thu, 27 May 2021 13:37:35 +0300 (MSK) Received: from vla5-3832771863b8.qloud-c.yandex.net (vla5-3832771863b8.qloud-c.yandex.net [2a02:6b8:c18:3417:0:640:3832:7718]) by vla1-af11d61edf22.qloud-c.yandex.net (mxback/Yandex) with ESMTP id 5Xgm5IcBJS-bYJu7Vwi; Thu, 27 May 2021 13:37:34 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1622111854; bh=pS9tRUOGbIT9IrA3lmIp2e6tLMAJblVT6CsujWn6W/Y=; h=Subject:To:From:Date:Message-ID; b=q3URym5+HUNT7xkVFm/811Lyvq7Pduq53zfp4Xigsq7W9AXLvnFUJq+KhG/hKQJ0O J58hYPL8E01F3snr4FshXkrSO6lY5Sp+ISBtZGBNLAeI4l+qwk9tJORV/BsgOtw3ry e969pNGfyV5bsmcegV8C3Q29koQgPDwcNsUrpah4= Authentication-Results: vla1-af11d61edf22.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by vla5-3832771863b8.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id zy4nRuWXIr-bYLWRc0N; Thu, 27 May 2021 13:37:34 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client certificate not present) Date: Thu, 27 May 2021 13:37:33 +0300 From: Eugen Konkov Message-ID: <14668694.20210527133733@yandex.ru> To: pgsql-performance@postgresql.org Subject: Count (select 1) subquery as constant MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello Pgsql-performance, To not flood network with many parameters I send only one and use `WITH` hack to reuse value inside query: WITH _app_period AS ( select app_period() ), ready AS ( SELECT min( lower( o.app_period ) ) OVER ( PARTITION BY agreement_id ) <@ (select * from _app_period) AS new_order, max( upper( o.app_period ) ) OVER ( PARTITION BY agreement_id ) <@ (select * from _app_period) AS del_order ,o.* FROM "order_bt" o LEFT JOIN acc_ready( 'Usage', (select * from _app_period), o ) acc_u ON acc_u.ready LEFT JOIN acc_ready( 'Invoice', (select * from _app_period), o ) acc_i ON acc_i.ready LEFT JOIN agreement a ON a.id = o.agreement_id LEFT JOIN xcheck c ON c.doc_id = o.id and c.doctype = 'OrderDetail' WHERE o.sys_period @> sys_time() AND o.app_period && (select * from _app_period) ) SELECT * FROM ready https://explain.depesz.com/s/kDCJ3#query but becaues of this `acc_ready` is not inlined and I get perfomance downgrade. Can we mark here (select * from _app_period) subquery as constant and allow to pass inline condition: >none of the actual arguments contain volatile expressions or subselects https://wiki.postgresql.org/wiki/Inlining_of_SQL_functions this subselect is not volatile and could be expanded to constant What do you think about this proposition? I expect it to spent 0.5ms instead of 14ms like here (I put app_period() explicitly) https://explain.depesz.com/s/iNTw 30 times faster! EXPLAIN( ANALYSE, FORMAT JSON, VERBOSE, settings, buffers ) WITH ready AS ( SELECT min( lower( o.app_period ) ) OVER ( PARTITION BY agreement_id ) <@ app_period() AS new_order, max( upper( o.app_period ) ) OVER ( PARTITION BY agreement_id ) <@ app_period() AS del_order ,o.* FROM "order_bt" o LEFT JOIN acc_ready( 'Usage', app_period(), o ) acc_u ON acc_u.ready LEFT JOIN acc_ready( 'Invoice', app_period(), o ) acc_i ON acc_i.ready LEFT JOIN agreement a ON a.id = o.agreement_id LEFT JOIN xcheck c ON c.doc_id = o.id and c.doctype = 'OrderDetail' WHERE o.sys_period @> sys_time() AND o.app_period && app_period() ) SELECT * FROM ready -- Best regards, Eugen Konkov