Re: Showing parallel status in \df+ - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Showing parallel status in \df+
Date
Msg-id 20160713172511.GH4028@tamriel.snowman.net
Whole thread Raw
In response to Re: Showing parallel status in \df+  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Showing parallel status in \df+
List pgsql-hackers
* Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> On 7/12/16 7:11 PM, Stephen Frost wrote:
> > I'm curious how it's useful and in what way \sf does not accomplish what
> > you use \df+ for.
>
> One main use is to see multiple related functions next to each other and
> compare their source code.  But also because one is used to \df and
> wants to see everything there and not in a different format like \sf.

Except that you don't actually get to see related functions next to each
other with \df+, you see them one after each other, which is not a very
useful diff comparison.  I don't see any value in the "because that's
how it's always been" argument.

> So ways to consolidate that would be supporting wildcards and multiple
> results in \sf, and/or the option to show a truncated version of the
> source code in \df+, or perhaps a \df++.

I don't mind adding wildcard support to \sf if there is interest.  I
dislike the "\df++" idea.  I have no idea how a "truncated version"
would ever be anything but noise for non-C/internal functions.

> > We've already had to change the structure of \df+; I'm not convinced
> > that avoiding doing so further now, just to do so again in the next
> > release, is actually a better answer than changing it now.
>
> We added a new column related to a new feature, which is hardly changing
> the structure.

I disagree.  Adding a column is certainly changing the structure, as is
removing one.  This certainly hasn't changed my opinion that it's
worthwhile to consider this change, even at this point in the release
cycle, given we need to make a change regardless.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: rethinking dense_alloc (HashJoin) as a memory context
Next
From: Tom Lane
Date:
Subject: Re: rethinking dense_alloc (HashJoin) as a memory context