Re: Showing parallel status in \df+

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Showing parallel status in \df+
Дата
Msg-id 20160713172511.GH4028@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Showing parallel status in \df+  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: Showing parallel status in \df+  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: rethinking dense_alloc (HashJoin) as a memory context
Следующее
От: Tom Lane
Дата:
Сообщение: Re: rethinking dense_alloc (HashJoin) as a memory context