>>> On Fri, May 9, 2008 at 3:53 PM, in message
<200805092053.m49Krq529089@momjian.us>, Bruce Momjian
<bruce@momjian.us> wrote:

> test=> \pset format wrapped
> Output format is wrapped.
> test=> \pset columns 50
> Target width for "wrapped" format is 50.
> test=> explain analyze select * from pg_type, pg_language;
> QUERY PLAN
> --------------------------------------------------
> Nested Loop (cost=1.03..25.86 rows=807 width=66
> 5) (actual time=0.037..4.528 rows=807 loops=1)
> -> Seq Scan on pg_type (cost=0.00..8.69 rows
> =269 width=555) (actual time=0.018..0.377 rows=2
> 69 loops=1)
> -> Materialize (cost=1.03..1.06 rows=3 width
> =110) (actual time=0.001..0.005 rows=3 loops=269
> )
> -> Seq Scan on pg_language (cost=0.00.
> .1.03 rows=3 width=110) (actual time=0.004..0.00
> 7 rows=3 loops=1)
> Total runtime: 5.490 ms
> (5 rows)
>
> Of course, running it on a 50-column display in 'aligned' mode isn't
> going to look good either.

With current production software, if I run in a 50 column window and
cut and paste into email, there aren't any line-ends in the email as
there would be with wrapped format.

-Kevin


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

Kevin Grittner wrote:
> >>> On Fri, May 9, 2008 at 3:53 PM, in message
> <200805092053.m49Krq529089@momjian.us>, Bruce Momjian
> <bruce@momjian.us> wrote:
>
> > test=> \pset format wrapped
> > Output format is wrapped.
> > test=> \pset columns 50
> > Target width for "wrapped" format is 50.
> > test=> explain analyze select * from pg_type, pg_language;
> > QUERY PLAN
> > --------------------------------------------------
> > Nested Loop (cost=1.03..25.86 rows=807 width=66
> > 5) (actual time=0.037..4.528 rows=807 loops=1)
> > -> Seq Scan on pg_type (cost=0.00..8.69 rows
> > =269 width=555) (actual time=0.018..0.377 rows=2
> > 69 loops=1)
> > -> Materialize (cost=1.03..1.06 rows=3 width
> > =110) (actual time=0.001..0.005 rows=3 loops=269
> > )
> > -> Seq Scan on pg_language (cost=0.00.
> > .1.03 rows=3 width=110) (actual time=0.004..0.00
> > 7 rows=3 loops=1)
> > Total runtime: 5.490 ms
> > (5 rows)
> >
> > Of course, running it on a 50-column display in 'aligned' mode isn't
> > going to look good either.
>
> With current production software, if I run in a 50 column window and
> cut and paste into email, there aren't any line-ends in the email as
> there would be with wrapped format.

I think that depends on what terminal you are using, but I do see some
of my terminal programs understand when wrapping happens and adjust the
cut/paste behavior.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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

Bruce Momjian escribió:

> Of course, running it on a 50-column display in 'aligned' mode isn't
> going to look good either.

This is what I get by pasting from a 50-column aligned psql (8.3):

QUERY PLAN
-------------------------------------------------------------------------------------------------------------------
Nested Loop (cost=1.03..25.86 rows=807 width=673) (actual time=4.349..20.973 rows=1897 loops=1)
-> Seq Scan on pg_type (cost=0.00..8.69 rows=269 width=563) (actual time=0.019..0.798 rows=271 loops=1)
-> Materialize (cost=1.03..1.06 rows=3 width=110) (actual time=0.018..0.033 rows=7 loops=271)
-> Seq Scan on pg_language (cost=0.00..1.03 rows=3 width=110) (actual time=4.296..4.312 rows=7 loops=1)
Total runtime: 35.041 ms
(5 lignes)


No unwanted line breaks. Of course, on the terminal it looks narrower,
but this doesn't affect cut'n paste behavior.

My conclusion is that we have to make very sure that "wrapped" is not
the default for explain.

FWIW this is expanded output:

alvherre=# \x
Affichage étendu activé.
alvherre=# explain analyze select * from pg_type, pg_language;
-[ RECORD 1 ]-----------------------------------------------------------------------------------------------------------------
QUERY PLAN | Nested Loop (cost=1.03..25.86 rows=807 width=673) (actual time=0.055..15.648 rows=1897 loops=1)
-[ RECORD 2 ]-----------------------------------------------------------------------------------------------------------------
QUERY PLAN | -> Seq Scan on pg_type (cost=0.00..8.69 rows=269 width=563) (actual time=0.019..0.623 rows=271 loops=1)
-[ RECORD 3 ]-----------------------------------------------------------------------------------------------------------------
QUERY PLAN | -> Materialize (cost=1.03..1.06 rows=3 width=110) (actual time=0.002..0.016 rows=7 loops=271)
-[ RECORD 4 ]-----------------------------------------------------------------------------------------------------------------
QUERY PLAN | -> Seq Scan on pg_language (cost=0.00..1.03 rows=3 width=110) (actual time=0.005..0.021 rows=7 loops=1)
-[ RECORD 5 ]-----------------------------------------------------------------------------------------------------------------
QUERY PLAN | Total runtime: 19.649 ms



--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

>>> Alvaro Herrera <alvherre@commandprompt.com> wrote:
> Bruce Momjian escribió:

> My conclusion is that we have to make very sure that "wrapped" is
not
> the default for explain.

This will cause me similar pain in other areas.

I'm glad I thought of an example with which others could easily
identify.

-Kevin


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

Bruce Momjian <bruce@momjian.us> writes:
> Now that psql '\pset format wrapped' is in CVS, we should consider when
> we want to use 'wrapped' format by default.

After experimenting for a bit, I'd say "never". This output format is
extremely ugly. Maybe if it had enough smarts not to break in the
middle of words ...

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

Tom Lane wrote:

Bruce Momjian &lt;bruce@momjian.us&gt; writes:



Now that psql '\pset format wrapped' is in CVS, we should consider when we want to use 'wrapped' format by default.



After experimenting for a bit, I'd say "never". This output format is extremely ugly. Maybe if it had enough smarts not to break in the middle of words ... regards, tom lane

Yet, wrapped is the same as aligned, if the lines fit!

Ugly to wrap? Yes.
Uglier than the sea of pipes you get when aligned output wraps itself?

Well I suppose you have to pick your preferred version of ugly.Â* I find itÂ* very hard to line up columns when presented with a sea of pipes, and highly annoying to constantly adjust my window width to see a query, especially if only one or two rows are too large.

Â*Â*Â* Â*Â* Â*Â* Â*Â* Â*Â* Â*Â* Â*Â* Â*Â* Â*Â* Â*Â* -Bryce

PS: it is true, I don't like the missing | bars on the current version.Â* I prefer that the grid cells be fully drawn, even if the contents don't fill the box

On Tue, May 13, 2008 at 4:12 PM, Bryce Nesbitt <bryce2@obviously.com> wrote:
>
> Tom Lane wrote:
>>
>> After experimenting for a bit, I'd say "never". This output format is
>> extremely ugly. Maybe if it had enough smarts not to break in the
>> middle of words ...
>> regards, tom lane
>
> Yet, wrapped is the same as aligned, if the lines fit!
>
> Ugly to wrap? Yes.
> Uglier than the sea of pipes you get when aligned output wraps itself?
>
> Well I suppose you have to pick your preferred version of ugly. I find it
> very hard to line up columns when presented with a sea of pipes, and highly
> annoying to constantly adjust my window width to see a query, especially if
> only one or two rows are too large.
>

I really like the idea of wrapping, but after playing with the format
a bit myself, I have to agree with Tom that breaking in the middle of
words produces some very nasty output.

If the format could be improved to only wrap on word boudaries, that
would increase its appeal dramatically.

Anybody got a rough idea how difficult it would be to add
word-awareness int o the wrapping code?

Cheers,
BJ

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

Brendan Jurd wrote:
> I really like the idea of wrapping, but after playing with the format
> a bit myself, I have to agree with Tom that breaking in the middle of
> words produces some very nasty output.
>
> If the format could be improved to only wrap on word boudaries, that
> would increase its appeal dramatically.
>
> Anybody got a rough idea how difficult it would be to add
> word-awareness int o the wrapping code?
>
> Cheers,
> BJ
>
It's not that hard to do.

I chose not to, when writing the patch, because it makes the result flow
over many more lines.
And regardless, it pretty much has to cut long "words", of which there
are many in typical SQL output.
And, I hardly ever read actual large blocks of English at the SQL
prompt, so: designing for that use case did
not float my boat at the time.
And, word wrapping messes with the cell contents more than I was
comfortable doing. With the current wrapping all whitespace is preserved
and apparent.

But, if your boat is floated, then by all means go for it.

-Bryce


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

Bryce Nesbitt wrote:
> It's not that hard to do.
>
> I chose not to, when writing the patch, because it makes the result flow
> over many more lines.
> And regardless, it pretty much has to cut long "words", of which there
> are many in typical SQL output.
> And, I hardly ever read actual large blocks of English at the SQL
> prompt, so: designing for that use case did
> not float my boat at the time.
> And, word wrapping messes with the cell contents more than I was
> comfortable doing. With the current wrapping all whitespace is preserved
> and apparent.
>
> But, if your boat is floated, then by all means go for it.

Yea, you could probably call it a 'chopped' format rather than a
'wrapped' format.

While I got a lot of feedback on screen width detection for wrapped, I
got little freedback on the display format. We can address that now.

I think we can wrap if there is whitespace within a few characters
before the break point, and use a dash if we have to break a word. Is
that what people want?

Also, about the format 'auto' idea that uses expanded display, I am
thinking because expanded is a separate setting and not a format, I
should just add a possible 'auto' value to the expanded format that
could be triggered by either 'aligned' or 'wrapped' formats when the
output doesn't fit on the screen.

(In hindsight, I think we should have had pager be on/auto/off rather
than always/on/off; the later is kind of confusing and would be
inconsistent if I add 'auto' to expanded.)

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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

Bruce Momjian wrote:

> I think we can wrap if there is whitespace within a few characters
> before the break point, and use a dash if we have to break a word. Is
> that what people want?

Ugh.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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