Pushed with minor fiddling with the toast-table code, and rather
more significant hacking on the partitioned-index code. Notably,
0003 had broken output of Tablespace: footers for everything except
indexes.
Argh, sorry for the review miss.
It's possibly not Justin's fault that that wasn't
Fabien COELHO writes:
> Field relnamespace oid in pg_class appears with pg 7.3, maybe it would be
> appropriate to guard agains older versions, with "pset.sversion >= 70300".
> It seems that there are other unguarded instances in "describe.c", so
> maybe this is considered too old.
Per the com
Find attached updated patches which also work against old servers.
I can't check that for sure.
* About toast table addition v7:
Patch applies cleanly, compiles, make check ok, no doc.
This addition show the main table of a toast table, which is useful.
Field relnamespace oid in pg_class
Find attached updated patches which also work against old servers.
1) avoid ::regnamespace; 2) don't PQgetvalue() fields which don't exist and
then crash.
>From 16b31dc1e4142ed6d0f5f7ed6d65c6184f546a3c Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 30 Apr 2019 19:05:53 -0500
Subject: [P
I realized that the test added to show-childs patch was listing partitioned
tables not indices..fixed.
>From 237f0bb2a048aa71726eff2580d01404ae3a98b4 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 30 Apr 2019 19:05:53 -0500
Subject: [PATCH v5] print table associated with given TOAST table
Sorry, I missed this until now.
On Sun, Jun 30, 2019 at 10:26:28AM +0200, Fabien COELHO wrote:
> *** About toast table v3:
>
> Patch applies cleanly, compiles, works for me.
>
> ISTM that the he query should be unambiguous: pg_catalog.pg_class instead of
> pg_class, add an alias (eg c), use c.FI
There are 3 independent patches associated to one thread and one CF entry.
*** About toast table v3:
Patch applies cleanly, compiles, works for me.
ISTM that the he query should be unambiguous: pg_catalog.pg_class instead
of pg_class, add an alias (eg c), use c.FIELD to access an attribute.
My previous patch missed a 1-line hunk, so resending.
>From 29e4c0b9700b9dee5f6ff2abc442e08e5221eb93 Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 30 Apr 2019 19:05:53 -0500
Subject: [PATCH v3] print table associated with given TOAST table
---
src/bin/psql/describe.c | 22 +
I'm continuing this thread with an additional change to slash dee for
partitioned indexes.
postgres=# \d ttz_i_idx
Partitioned index "public.ttz_i_idx"
Column | Type | Key? | Definition
+-+--+
i | integer | yes | i
btree, for table "public.ttz"
Number o
Robert Haas writes:
> I think it's unjustifiable to show this in \d output. But maybe in
> \d+ output it could be justified, or perhaps in the \d++ which I seem
> to recall Alvaro proposing someplace recently.
Yeah, if we're going to do that (show a table's toast table) I would
want to bury it i
On Tue, May 7, 2019 at 6:03 PM Stephen Frost wrote:
> Alright, maybe I'm not the best representation of our user base, but I
> sure type 'select oid,* from pg_class where relname = ...' with some
> regularity, mostly to get the oid to then go do something else. Having
> the relfilenode would be n
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Having our test framework deny us useful features just strikes me as
> > bizarre.
>
> This is presuming that it's useful, which is debatable IMO.
> I think most people will find it useless noise almost all of the time.
Stephen Frost writes:
> Having our test framework deny us useful features just strikes me as
> bizarre.
This is presuming that it's useful, which is debatable IMO.
I think most people will find it useless noise almost all of the time.
regards, tom lane
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, May 7, 2019 at 11:30 AM Stephen Frost wrote:
> > > Not unless you want to break every regression test that uses \d.
> > > Instability of the output is also a reason not to show the
> > > toast table's name in the parent's \d[+].
>
On Tue, May 7, 2019 at 11:30 AM Stephen Frost wrote:
> > Not unless you want to break every regression test that uses \d.
> > Instability of the output is also a reason not to show the
> > toast table's name in the parent's \d[+].
>
> So we need a way to turn it off. That doesn't seem like it'd b
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Rafia Sabih writes:
> >>> 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 usel
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Rafia Sabih writes:
>>> 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
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Rafia Sabih writes:
> > On Fri, 3 May 2019 at 16:27, Justin Pryzby 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
On Mon, May 6, 2019 at 12:26 PM Andres Freund wrote:
> I'm not convinced by that. I've certainly many a time wrote queries
> against pg_class to figure out which relation a toast table belongs
> to. E.g. after looking at the largest relations in the system, looking
> at pg_stat_*_tables, after see
On 2019-May-06, Justin Pryzby wrote:
> 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'm with Andres -- while it's admittedly a rare need, it is a real one.
Sometimes I wish for \d++ which would displa
Hi,
On 2019-05-06 11:58:18 -0400, Tom Lane wrote:
> 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.
I'm not convinced by that. I've certainly many a time wrote queries
against pg_c
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 toas
Rafia Sabih writes:
> On Fri, 3 May 2019 at 16:27, Justin Pryzby 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
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.
> > >
> >
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
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_toa
26 matches
Mail list logo
