Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fYV8R-0006JL-V0 for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Jun 2018 11:30:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fYV8N-0004sS-RO for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Jun 2018 11:30:43 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fYV8N-0004s6-HF for pgsql-hackers@lists.postgresql.org; Thu, 28 Jun 2018 11:30:43 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fYV8L-0003EV-75 for pgsql-hackers@postgresql.org; Thu, 28 Jun 2018 11:30:42 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 99FA621ECD; Thu, 28 Jun 2018 07:30:40 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 28 Jun 2018 07:30:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=1v728JfyVNCgE3FiXPZjKSQ6l63HCk+fgQF732Y+w6k=; b=Gys8QP0A iP6qGawHk43T7+mctLK0EZu7uf0YTEc19rP9mo3lRCsQkbQoz8m8qdJ/oNZCIjL9 VpiYDzpzoQHDPRLTFQqZ8iTR7PLtnjoGDBdMtmkeAfbVuMfmPk5vmB6QrnOhVnoH Q06IQ90xrvMXnCwwvmKoJOho6bTIyuWsCAd4CICDrOEdPn0rtNxDWwFnrBBG2LA2 itDX0sMv6zYZ+4tN7WGEzWbW1+5EgKrkJfivVsxWWwWHLj8Xlchq0iAofq9eEdf6 dFZyZw+nPRUu46SmrcsEQw2Jxda8fCerV/lAoZDrQJgJFOeFFWfiBqrZjlwUub27 JN5ERFopRzzuLA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=1v728JfyVNCgE3FiXPZjKSQ6l63HC k+fgQF732Y+w6k=; b=MLa2RIdEOePshjhji9EcGiMPHOR0E0RVnL7sQ3z3mkoZP pxEkd2br1T4whGq9PoHYps1D/kVKKJ/sQFnRPbBnavYHISIb5y2tDgCmWNzEVyPL B5QEOqMZGpySvFAgyy5Rq6TvHpZKyo9FZ6ilmjvZGs27OS5j/w2wD4CGgY8Ie/52 D8Gv8K04M8GpIeYOMqK/z+jrmj41+60w2MUICwqnbwqgBRHdecVPfzJ5YWMoOQ0q +q5xBowz9gneQN2o6eJEJMo57ujcOTXMCCy1ifL4gaB568nSeO/75eeYnGDAm83A rfpaAQRQUQJKvQdlSHGojvvCksQxsrNpq0t2c7EVg== X-ME-Proxy: X-ME-Sender: Received: from paquier.xyz (c137162.net61215.cablenet.ne.jp [61.215.137.162]) by mail.messagingengine.com (Postfix) with ESMTPA id 98440E482E; Thu, 28 Jun 2018 07:30:38 -0400 (EDT) Date: Thu, 28 Jun 2018 20:30:35 +0900 From: Michael Paquier To: Peter Eisentraut Cc: Amit Langote , Pg Hackers Subject: Re: partition tree inspection functions Message-ID: <20180628113035.GA1716@paquier.xyz> References: <8d00e51a-9a51-ad02-d53e-ba6bf50b2e52@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jun 28, 2018 at 12:37:14PM +0200, Peter Eisentraut wrote: > I'm thinking, an SQL query might be more efficient if you want to > qualify the query further. For example, give me all tables in this tree > that match '2018'. If you wrote your functions as SQL-language > functions, the optimizer could perhaps inline them and optimize them > further. Are you thinking about SQL functions here? Here is an example of query able to fetch an entire partition tree. WITH RECURSIVE partition_info (relid, relname, relsize, relispartition, relkind) AS ( SELECT oid AS relid, relname, pg_relation_size(oid) AS relsize, relispartition, relkind FROM pg_catalog.pg_class WHERE relname = 'your_parent_table_name_here' AND relkind = 'p' UNION ALL SELECT c.oid AS relid, c.relname AS relname, pg_relation_size(c.oid) AS relsize, c.relispartition AS relispartition, c.relkind AS relkind FROM partition_info AS p, pg_catalog.pg_inherits AS i, pg_catalog.pg_class AS c WHERE p.relid = i.inhparent AND c.oid = i.inhrelid AND c.relispartition ) SELECT * FROM partition_info; Getting the direct parent is immediate, and getting the top-most parent would be rather similar to that. Not much elegant in my opinion, but that's mainly a matter of taste? -- Michael --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAls0xtsACgkQnvQgOdby QH1j6g//YZVnowAkpIv9+YTCPkYvIRTcz6CWoAcNvi/xpOcTWN6yN7VYOZuoS9zt U/f7tWAa1nqM3mWxnyfk+05FwJfnH5JmRionK3pCX+jncCxDwEuPLnc8S2SuQyXR 30clRh8E/xVtzWx77euoSjiv/Vxc47cJe3xd1Ij+EUL61yaSEYZnMOmLv+jqWiRB ksBOMSSDq+/4FJ6FwrZRELDOsNqYhWR9sMdmPRboLKis1c/YCVxmHMXETV6jvuFR N2mAL4MSMIHc7hmzPbiC/KbWn0FFeDrzzZ1q080DCEhbLQA/1gP94lOppsvuEgeq l0UldbJ08yFvXyOgTCCZyLn2kO+J8TGkHelacM0GtLKpjwVgho8Ay87HPaby/VlO iYXuRyDFA0UEFGQXoSBs3SN/BeTXddZf0+cylt86zpX67sGXN+lR+C/lEL2xP9Ae QJro2Em7o4y4o5rCaB2qQRPPwdB4WlMMZVNizI/hNu7+NYCuRiAdE08t6TcfTlFp 38g/b+SOG9Orhmpq97BfmTN5gsWpe+ES+N9P8ZGhl9Whh8oDGaeCZnuZB/FbKfkM SUQtxDGUBNgvxgxH3LgMI9lexhZlMWxBaPmyCUErxArqoi+K1A9lGVPpRIJTSC5k Tmve73seHhwFTiTTMQsBds2Mme/bTR9P/36T2JnGnUQH2tggOXk= =b8gC -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz--