Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hNgON-0003Xn-OW for pgsql-hackers@arkaria.postgresql.org; Mon, 06 May 2019 16:23:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hNgOM-0006qR-JN for pgsql-hackers@arkaria.postgresql.org; Mon, 06 May 2019 16:23:02 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hNgOM-0006c2-0s for pgsql-hackers@lists.postgresql.org; Mon, 06 May 2019 16:23:02 +0000 Received: from mail-io1-xd42.google.com ([2607:f8b0:4864:20::d42]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hNgOE-0000Rv-IM for pgsql-hackers@postgresql.org; Mon, 06 May 2019 16:23:00 +0000 Received: by mail-io1-xd42.google.com with SMTP id v7so5222225iob.10 for ; Mon, 06 May 2019 09:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=lzN1NI9p/bhNXRY2yj8JSSit9XyTCr9SwA3RD+dFVJA=; b=0NfRy8s63xO2k0d0tQbqhPE3/cceFNPHfaJkCkkl/Lg9fuYn/HrO7P646qx+LPSI0Y oOrrxSFO/nc6NqUIZFuCPBrNNyviNSqV/+0eiwHhBVA/1ScBE9l5cI1bCkokAzn5WkiR In8/YN+uVrNoSjeMCoOgLAyeuwoh5NY8Km+L3pI9g1Wo8kbxZvV1gKTUl/ccwhkutS1w 6nUvmzB1HGQ+nUVYygXk6H/wRVKKb8Qg2G0IoRF/932Uz5hkQcj7lhLmPT+8UdNMf8hu stHFIvUVKHE+ciZzVVfqW8t6W9e4noxUUy+iNpQyldWlbYg/lrpcFdI5LP4zQZVetFHn wQjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=lzN1NI9p/bhNXRY2yj8JSSit9XyTCr9SwA3RD+dFVJA=; b=nlMlJb1A8cbCHq+qG+YcSo1srVJUsfR5xGIY96gjfJp0TWbDgcbHvVDkWRC4fvhBSM K+lPglGG7mc4TE90n44KPzOlDJ6z2aTAfWIbO5l2/qhRLCjYd5aiTqJ4m9L+Kht9eQNV KOfk3X+x2HRByzPH25VVwe6t9miVNxh5sTery61wC1LfklJq0F2BqEO2iTx4PD1TYVTp FrmE7A/UCjaXj8MFEbWZYg+HRSG/dZ7RsIP40S5B0IDcPvgHW9qm5661jmKZ2CJOeIcS DvrIIcG7jDeZ4v0WMf2Dj5l28Jgk2KKquV6+pSpPuVauIREkMI2JAoiK+B5vFYPKUpxg wrPw== X-Gm-Message-State: APjAAAU8y/J13XaUvXIwBFXPqvlu34DloXcJHFSDtb2Tv2n0VeAtRD6C r00yfSx15Y1FZ0hCq/hDuJRC/A== X-Google-Smtp-Source: APXvYqzqHlljpUx//9yOLdRqk8OEnn7p3aL6gTmTxnPf3cr/0AX6oSP5wfhs3CjhKCirhV5Teez5DA== X-Received: by 2002:a5d:9c85:: with SMTP id p5mr9111825iop.13.1557159773809; Mon, 06 May 2019 09:22:53 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id i72sm8929021itc.11.2019.05.06.09.22.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 May 2019 09:22:53 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id ED026800A44; Mon, 6 May 2019 11:22:51 -0500 (CDT) Date: Mon, 6 May 2019 11:22:51 -0500 From: Justin Pryzby To: Rafia Sabih Cc: PostgreSQL-development Subject: Re: make \d pg_toast.foo show its indices ; and, \d toast show its main table Message-ID: <20190506162251.GN3925@telsasoft.com> References: <20190422154902.GH14223@telsasoft.com> <20190503142721.GC3925@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, May 06, 2019 at 09:13:52AM +0200, Rafia Sabih wrote: > On Fri, 3 May 2019 at 16:27, Justin Pryzby wrote: > > > > On Fri, May 03, 2019 at 02:55:47PM +0200, Rafia Sabih wrote: > > > On Mon, 22 Apr 2019 at 17:49, Justin Pryzby wrote: > > > > > > > > It's deliberate that \dt doesn't show toast tables. > > > > \d shows them, but doesn't show their indices. > > > > > > > > It seems to me that their indices should be shown, without having to think and > > > > know to query pg_index. > > > > > > > > postgres=# \d pg_toast.pg_toast_2600 > > > > TOAST table "pg_toast.pg_toast_2600" > > > > Column | Type > > > > ------------+--------- > > > > chunk_id | oid > > > > chunk_seq | integer > > > > chunk_data | bytea > > > > Indexes: > > > > "pg_toast_2600_index" PRIMARY KEY, btree (chunk_id, chunk_seq) > > > > > > +1. > > > > Thanks - what about also showing the associated non-toast table ? > > > IMHO, what makes more sense is to show the name of associated toast > table in the \dt+ of the normal table. Perhaps ... but TOAST is an implementation detail, and I think it should rarely be important to know the toast table for a given table. I think it's more useful to go the other way (at least), to answer questions when pg_toast.* table shows up in a query like these: - SELECT relpages, relname FROM pg_class ORDER BY 1 DESC; - SELECT COUNT(1), relname FROM pg_class c JOIN pg_buffercache b ON b.relfilenode=c.oid GROUP BY 2 ORDER BY 1 DESC LIMIT 9; Justin