proposal: EXPLAIN ANALYZE formatting

On 1/28/17 2:36 AM, Pavel Stehule wrote:

Now EXPLAIN ANALYZE produce too wide rows for usage in presentations

What do you think about possibility to implement >>optional<<
alternative formatting.

Now:

node name (estimation) (actual)

Alternative:

node name (estimation)
(actual)

I think that could be useful, even outside of presentations.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2017-01-28 16:22 GMT+01:00 Peter Eisentraut <
peter.eisentraut@2ndquadrant.com>:

On 1/28/17 2:36 AM, Pavel Stehule wrote:

Now EXPLAIN ANALYZE produce too wide rows for usage in presentations

What do you think about possibility to implement >>optional<<
alternative formatting.

Now:

node name (estimation) (actual)

Alternative:

node name (estimation)
(actual)

I think that could be useful, even outside of presentations.

There is another variant with less white space

node name
(estimation)
(actual)

Regards

Pavel

Pavel Stehule <pavel.stehule@gmail.com> writes:

Now EXPLAIN ANALYZE produce too wide rows for usage in presentations

What do you think about possibility to implement >>optional<< alternative
formatting.
Now:
node name (estimation) (actual)
Alternative:
node name (estimation)
(actual)

Seems like that would make a difference in only a tiny minority of
situations. In a deeply nested plan you'll have trouble no matter
what, and it's not uncommon that the node name line isn't the widest
thing anyway.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2017-01-28 17:09 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:

Pavel Stehule <pavel.stehule@gmail.com> writes:

Now EXPLAIN ANALYZE produce too wide rows for usage in presentations

What do you think about possibility to implement >>optional<< alternative
formatting.
Now:
node name (estimation) (actual)
Alternative:
node name (estimation)
(actual)

Seems like that would make a difference in only a tiny minority of
situations. In a deeply nested plan you'll have trouble no matter
what, and it's not uncommon that the node name line isn't the widest
thing anyway.

It is related to presentation where you have to use large type - and where
usually don't present complex nested plans, or you present only fragments.

A output of EXPLAIN is usually ok - EXPLAIN ANALYZE does a overflow

This feature is in nice to have category - probably interesting for
lectures or presenters only - can helps and doesn't need lot of work. So I
am ask for community opinion.

The result should not be exactly how I proposed - any form what is more
friendly for tiny monitor (projectors) is welcome

Regards

Pavel

Pavel Stehule <pavel.stehule@gmail.com> writes:

2017-01-28 17:09 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:

Seems like that would make a difference in only a tiny minority of
situations. In a deeply nested plan you'll have trouble no matter
what, and it's not uncommon that the node name line isn't the widest
thing anyway.

It is related to presentation where you have to use large type - and where
usually don't present complex nested plans, or you present only fragments.

Sure, but then you're whacking around the text anyway while you put it
into your slides. I doubt anyone would have trouble understanding your
slides if you break up the lines like that, whether or not it's exactly
what you'd get out of EXPLAIN itself.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2017-01-28 17:58 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:

Pavel Stehule <pavel.stehule@gmail.com> writes:

2017-01-28 17:09 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:

Seems like that would make a difference in only a tiny minority of
situations. In a deeply nested plan you'll have trouble no matter
what, and it's not uncommon that the node name line isn't the widest
thing anyway.

It is related to presentation where you have to use large type - and

where

usually don't present complex nested plans, or you present only

fragments.

Sure, but then you're whacking around the text anyway while you put it
into your slides. I doubt anyone would have trouble understanding your
slides if you break up the lines like that, whether or not it's exactly
what you'd get out of EXPLAIN itself.

I cannot to break lines when I use psql and mirrored screen.

Regards

Pavel

On 29/01/17 05:31, Pavel Stehule wrote:

2017-01-28 17:09 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us
<mailto:tgl@sss.pgh.pa.us>>:

Pavel Stehule <pavel.stehule@gmail.com
<mailto:pavel.stehule@gmail.com>> writes:

Now EXPLAIN ANALYZE produce too wide rows for usage in presentations

What do you think about possibility to implement >>optional<<

alternative

formatting.
Now:
node name (estimation) (actual)
Alternative:
node name (estimation)
(actual)

Seems like that would make a difference in only a tiny minority of
situations. In a deeply nested plan you'll have trouble no matter
what, and it's not uncommon that the node name line isn't the widest
thing anyway.

It is related to presentation where you have to use large type - and
where usually don't present complex nested plans, or you present only
fragments.

A output of EXPLAIN is usually ok - EXPLAIN ANALYZE does a overflow

This feature is in nice to have category - probably interesting for
lectures or presenters only - can helps and doesn't need lot of work.
So I am ask for community opinion.

The result should not be exactly how I proposed - any form what is
more friendly for tiny monitor (projectors) is welcome

Regards

Pavel

regards, tom lane

How about have a GUC to control the formatting of how it is displayed?

Could also include maximum line width (default 'infinite'), and word
wrapping rules, ...

Cheers,
Gavin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 1/28/17 3:24 PM, Gavin Flower wrote:

How about have a GUC to control the formatting of how it is displayed?

Could also include maximum line width (default 'infinite'), and word
wrapping rules, ...

You can already configure that in psql.

You can also use the yaml format if you want to use less horizontal
space. (I have used that in presentations.)

What I liked about it is that it makes it a bit easier to compare the
estimate and actual for each node.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

What I liked about it is that it makes it a bit easier to compare the
estimate and actual for each node.

Hmm, you'd have to make some effort to line up those fields, if you
wanted that to be a thing.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers