Re: make \d pg_toast.foo show its indices - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: make \d pg_toast.foo show its indices
Date
Msg-id 20190507151600.GH6197@tamriel.snowman.net
Whole thread Raw
In response to Re: make \d pg_toast.foo show its indices  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: make \d pg_toast.foo show its indices  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Rafia Sabih <rafia.pghackers@gmail.com> writes:
> > On Fri, 3 May 2019 at 16:27, Justin Pryzby <pryzby@telsasoft.com> wrote:
> >> 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.
>
> I'm not for that: it's useless information in at least 99.44% of cases.

I don't think I'd put it in \dt+, but the toast table is still
pg_toast.pg_toast_{relOid}, right?  What about showing the OID of the
table in the \d output, eg:

=> \d comments
           Table "public.comments" (50788)
 Column  |  Type   | Collation | Nullable |   Default

etc?

> Possibly it is useful in the other direction as Justin suggests.
> Not sure though --- generally, if you're looking at a specific
> toast table, you already know which table is its parent.  But
> maybe confirmation is a good thing.

As mentioned elsewhere, there are certainly times when you don't know
that info and if you're looking at the definition of a TOAST table,
which isn't terribly complex, it seems like a good idea to go ahead and
include the table it's the TOAST table for.

> That seems off-topic for this thread though.  I agree with the
> stated premise that \d on a toast table should show all the same
> information \d on a regular table would.

+1

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: accounting for memory used for BufFile during hash joins
Next
From: Tom Lane
Date:
Subject: Re: make \d pg_toast.foo show its indices