Re: [HACKERS] controlling psql's use of the pager a bit more

[Andrew Dunstan]

On 12/21/2014 02:22 PM, Andrew Dunstan wrote:


On 11/15/2014 05:56 PM, Andrew Dunstan wrote:


On 11/13/2014 11:41 AM, Andrew Dunstan wrote:


On 11/13/2014 11:09 AM, Tom Lane wrote:

Andrew Dunstan and...@dunslane.net writes:
I often get annoyed because psql is a bit too aggressive when it 
decides
whether to put output through the pager, and the only way to avoid 
this
is to turn the pager off (in which case your next query might dump 
many
thousands of lines to the screen). I'd like a way to be able to 
specify
a minumum number of lines of output before psql would invoke the 
pager,

rather than just always using the terminal window size.
Are you saying you'd want to set the threshold to *more* than the 
window

height?  Why?



Because I might be quite happy with 100 or 200 lines I can just 
scroll in my terminal's scroll buffer, but want to use the pager for 
more than that. This is useful especially if I want to scroll back 
and see the results from a query or two ago.








This patch shows more or less what I had in mind.

However, there is more work to do. As Tom noted upthread, psql's 
calculation of the number of lines is pretty bad. For example, if I do:


   \pset pager_min_lines 100
   select * from generate_series(1,50);

the pager still gets invoked, which is unfortunate to say the least.

So I'm going to take a peek at that.




The over-eager invocation of the pager due to double counting of lines 
got fixed recently, so here's a slightly updated patch for a 
pager_min_lines setting, including docco.






The assigned reviewer hasn't done a review and hasn't responded to 
email. If there are no other comments I propose to commit this shortly.


cheers

andrew


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

Re: [HACKERS] controlling psql's use of the pager a bit more

[Andres Freund]

On 2014-12-21 14:22:10 -0500, Andrew Dunstan wrote:
 @@ -301,11 +301,11 @@ slashUsage(unsigned short int pager)
   * show list of available variables (options) from command line
   */
  void
 -helpVariables(unsigned short int pager)
 +helpVariables(unsigned short int pager,  int pager_min_lines)
  {
   FILE   *output;

Odd space before pager_min_lines.

Without having actually tried it, it looks clean enough to me. If
there's more pager options we might at some point introduce a pager
options struct instead adding more options to PageOutput. But for now it
seems ok enough.

Greetings,

Andres Freund


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

Re: [HACKERS] controlling psql's use of the pager a bit more

[Andrew Dunstan]

On 03/26/2015 11:10 AM, Tom Lane wrote:

Andres Freund and...@2ndquadrant.com writes:

Without having actually tried it, it looks clean enough to me. If
there's more pager options we might at some point introduce a pager
options struct instead adding more options to PageOutput. But for now it
seems ok enough.

My reaction is that now would be the time to do that, really.  This is
messing up the argument lists of what seems like a whole lot of functions,
and I have little faith that this is the last argument we'll need to add.





OK, this version only changes the signature of one function: 
PageOutput(), which instead of taking just the pager flag takes a 
pointer to the whole printTableOpt structure that contains both the 
pager and pager_min_lines settings (NULL means don't use the pager). 
That makes the patch smaller and less invasive, and a bit more future-proof.


cheers

andrew
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index a637001..a33e460 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -2236,6 +2236,18 @@ lo_import 152801
   /varlistentry
 
   varlistentry
+  termliteralpager_min_lines/literal/term
+  listitem
+  para
+  If literalpager_min_lines/ is set to a number greater than the
+  page height, the pager program will not be called unless there are
+  at least this many lines of output to show. The default setting
+  is 0.
+  /para
+  /listitem
+  /varlistentry
+
+  varlistentry
   termliteralrecordsep/literal/term
   listitem
   para
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 7c9f28d..e64c033 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -1071,7 +1071,8 @@ exec_command(const char *cmd,
 			static const char *const my_list[] = {
 border, columns, expanded, fieldsep, fieldsep_zero,
 footer, format, linestyle, null,
-numericlocale, pager, recordsep, recordsep_zero,
+numericlocale, pager, pager_min_lines,
+recordsep, recordsep_zero,
 tableattr, title, tuples_only,
 unicode_border_linestyle,
 unicode_column_linestyle,
@@ -1265,7 +1266,7 @@ exec_command(const char *cmd,
 	lines++;
 }
 
-output = PageOutput(lineno, pset.popt.topt.pager);
+output = PageOutput(lineno, (pset.popt.topt));
 is_pager = true;
 			}
 			else
@@ -2519,6 +2520,13 @@ do_pset(const char *param, const char *value, printQueryOpt *popt, bool quiet)
 			popt-topt.pager = 1;
 	}
 
+	/* set minimum lines for pager use */
+	else if (strcmp(param, pager_min_lines) == 0)
+	{
+		if (value)
+			popt-topt.pager_min_lines = atoi(value);
+	}
+
 	/* disable (x rows) footer */
 	else if (strcmp(param, footer) == 0)
 	{
@@ -2640,6 +2648,13 @@ printPsetInfo(const char *param, struct printQueryOpt *popt)
 			printf(_(Pager usage is off.\n));
 	}
 
+	/* show minimum lines for pager use */
+	else if (strcmp(param, pager_min_lines) == 0)
+	{
+		printf(_(Pager won't be used for less than %d lines\n),
+			   popt-topt.pager_min_lines);
+	}
+
 	/* show record separator for unaligned text */
 	else if (strcmp(param, recordsep) == 0)
 	{
@@ -2792,6 +2807,8 @@ pset_value_string(const char *param, struct printQueryOpt *popt)
 		return pstrdup(pset_bool_string(popt-topt.numericLocale));
 	else if (strcmp(param, pager) == 0)
 		return psprintf(%d, popt-topt.pager);
+	else if (strcmp(param, pager_min_lines) == 0)
+		return psprintf(%d, popt-topt.pager_min_lines);
 	else if (strcmp(param, recordsep) == 0)
 		return pset_quoted_string(popt-topt.recordSep.separator
   ? popt-topt.recordSep.separator
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
index 15488ff..2e7d9a4 100644
--- a/src/bin/psql/common.c
+++ b/src/bin/psql/common.c
@@ -1337,7 +1337,7 @@ ExecQueryUsingCursor(const char *query, double *elapsed_msec)
 			 * If query requires multiple result sets, hack to ensure that
 			 * only one pager instance is used for the whole mess
 			 */
-			pset.queryFout = PageOutput(10, my_popt.topt.pager);
+			pset.queryFout = PageOutput(10, (my_popt.topt));
 			did_pager = true;
 		}
 
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index ac0dc27..2da444b 100644
--- a/src/bin/psql/help.c
+++ b/src/bin/psql/help.c
@@ -65,7 +65,7 @@ usage(unsigned short int pager)
 		}
 	}
 
-	output = PageOutput(59, pager);
+	output = PageOutput(59, pager ? (pset.popt.topt) : NULL);
 
 	fprintf(output, _(psql is the PostgreSQL interactive terminal.\n\n));
 	fprintf(output, _(Usage:\n));
@@ -158,7 +158,7 @@ slashUsage(unsigned short int pager)
 
 	currdb = PQdb(pset.db);
 
-	output = PageOutput(103, pager);
+	output = PageOutput(103, pager ? (pset.popt.topt) : NULL);
 
 	/* if you add/remove a line here, change the row count above */
 
@@ -305,7 +305,7 @@ helpVariables(unsigned short int pager)
 {
 	FILE	   *output;
 
-	output = 

Re: [HACKERS] controlling psql's use of the pager a bit more

[Andrew Dunstan]

On 03/26/2015 11:10 AM, Tom Lane wrote:

Andres Freund and...@2ndquadrant.com writes:

Without having actually tried it, it looks clean enough to me. If
there's more pager options we might at some point introduce a pager
options struct instead adding more options to PageOutput. But for now it
seems ok enough.

My reaction is that now would be the time to do that, really.  This is
messing up the argument lists of what seems like a whole lot of functions,
and I have little faith that this is the last argument we'll need to add.






*grumble*

OK , I'll take a look.

cheers

andrew


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

Re: [HACKERS] controlling psql's use of the pager a bit more

[Tom Lane]

Andres Freund and...@2ndquadrant.com writes:
 Without having actually tried it, it looks clean enough to me. If
 there's more pager options we might at some point introduce a pager
 options struct instead adding more options to PageOutput. But for now it
 seems ok enough.

My reaction is that now would be the time to do that, really.  This is
messing up the argument lists of what seems like a whole lot of functions,
and I have little faith that this is the last argument we'll need to add.

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

Re: [HACKERS] controlling psql's use of the pager a bit more

[Andrew Dunstan]

On 11/15/2014 05:56 PM, Andrew Dunstan wrote:


On 11/13/2014 11:41 AM, Andrew Dunstan wrote:


On 11/13/2014 11:09 AM, Tom Lane wrote:

Andrew Dunstan and...@dunslane.net writes:
I often get annoyed because psql is a bit too aggressive when it 
decides
whether to put output through the pager, and the only way to avoid 
this
is to turn the pager off (in which case your next query might dump 
many
thousands of lines to the screen). I'd like a way to be able to 
specify
a minumum number of lines of output before psql would invoke the 
pager,

rather than just always using the terminal window size.
Are you saying you'd want to set the threshold to *more* than the 
window

height?  Why?



Because I might be quite happy with 100 or 200 lines I can just 
scroll in my terminal's scroll buffer, but want to use the pager for 
more than that. This is useful especially if I want to scroll back 
and see the results from a query or two ago.








This patch shows more or less what I had in mind.

However, there is more work to do. As Tom noted upthread, psql's 
calculation of the number of lines is pretty bad. For example, if I do:


   \pset pager_min_lines 100
   select * from generate_series(1,50);

the pager still gets invoked, which is unfortunate to say the least.

So I'm going to take a peek at that.




The over-eager invocation of the pager due to double counting of lines 
got fixed recently, so here's a slightly updated patch for a 
pager_min_lines setting, including docco.


cheers

andrew
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index e7fcc73..4201847 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -2236,6 +2236,18 @@ lo_import 152801
   /varlistentry
 
   varlistentry
+  termliteralpager_min_lines/literal/term
+  listitem
+  para
+  If literalpager_min_lines/ is set to a number greater than the
+  page height, the pager program will not be called unless there are
+  at least this many lines of output to show. The default setting
+  is 0.
+  /para
+  /listitem
+  /varlistentry
+
+  varlistentry
   termliteralrecordsep/literal/term
   listitem
   para
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index c7a17d7..2703850 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -807,7 +807,7 @@ exec_command(const char *cmd,
 opt[--len] = '\0';
 		}
 
-		helpSQL(opt, pset.popt.topt.pager);
+		helpSQL(opt, pset.popt.topt.pager, pset.popt.topt.pager_min_lines);
 		free(opt);
 	}
 
@@ -1074,7 +1074,8 @@ exec_command(const char *cmd,
 			static const char *const my_list[] = {
 border, columns, expanded, fieldsep, fieldsep_zero,
 footer, format, linestyle, null,
-numericlocale, pager, recordsep, recordsep_zero,
+numericlocale, pager, pager_min_lines,
+recordsep, recordsep_zero,
 tableattr, title, tuples_only,
 unicode_border_linestyle,
 unicode_column_linestyle,
@@ -1268,7 +1269,8 @@ exec_command(const char *cmd,
 	lines++;
 }
 
-output = PageOutput(lineno, pset.popt.topt.pager);
+output = PageOutput(lineno, pset.popt.topt.pager,
+	pset.popt.topt.pager_min_lines);
 is_pager = true;
 			}
 			else
@@ -1520,13 +1522,13 @@ exec_command(const char *cmd,
 	OT_NORMAL, NULL, false);
 
 		if (!opt0 || strcmp(opt0, commands) == 0)
-			slashUsage(pset.popt.topt.pager);
+			slashUsage(pset.popt.topt.pager, pset.popt.topt.pager_min_lines);
 		else if (strcmp(opt0, options) == 0)
-			usage(pset.popt.topt.pager);
+			usage(pset.popt.topt.pager, pset.popt.topt.pager_min_lines);
 		else if (strcmp(opt0, variables) == 0)
-			helpVariables(pset.popt.topt.pager);
+			helpVariables(pset.popt.topt.pager, pset.popt.topt.pager_min_lines);
 		else
-			slashUsage(pset.popt.topt.pager);
+			slashUsage(pset.popt.topt.pager, pset.popt.topt.pager_min_lines);
 	}
 
 #if 0
@@ -2522,6 +2524,13 @@ do_pset(const char *param, const char *value, printQueryOpt *popt, bool quiet)
 			popt-topt.pager = 1;
 	}
 
+	/* set minimum lines for pager use */
+	else if (strcmp(param, pager_min_lines) == 0)
+	{
+		if (value)
+			popt-topt.pager_min_lines = atoi(value);
+	}
+
 	/* disable (x rows) footer */
 	else if (strcmp(param, footer) == 0)
 	{
@@ -2643,6 +2652,13 @@ printPsetInfo(const char *param, struct printQueryOpt *popt)
 			printf(_(Pager usage is off.\n));
 	}
 
+	/* show minimum lines for pager use */
+	else if (strcmp(param, pager_min_lines) == 0)
+	{
+		printf(_(Pager won't be used for less than %d lines\n),
+			   popt-topt.pager_min_lines);
+	}
+
 	/* show record separator for unaligned text */
 	else if (strcmp(param, recordsep) == 0)
 	{
@@ -2795,6 +2811,8 @@ pset_value_string(const char *param, struct printQueryOpt *popt)
 		return pstrdup(pset_bool_string(popt-topt.numericLocale));
 	else if (strcmp(param, pager) == 0)
 		return psprintf(%d, 

Re: [HACKERS] controlling psql's use of the pager a bit more

[Alvaro Herrera]

Andrew Dunstan wrote:

 However, there is more work to do. As Tom noted upthread, psql's calculation
 of the number of lines is pretty bad. For example, if I do:
 
\pset pager_min_lines 100
select * from generate_series(1,50);
 
 the pager still gets invoked, which is unfortunate to say the least.
 
 So I'm going to take a peek at that.

Any luck there?

-- 
Álvaro Herrerahttp://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

Re: [HACKERS] controlling psql's use of the pager a bit more

[Andrew Dunstan]

On 12/04/2014 03:53 PM, Alvaro Herrera wrote:

Andrew Dunstan wrote:


However, there is more work to do. As Tom noted upthread, psql's calculation
of the number of lines is pretty bad. For example, if I do:

\pset pager_min_lines 100
select * from generate_series(1,50);

the pager still gets invoked, which is unfortunate to say the least.

So I'm going to take a peek at that.

Any luck there?




Some, yes, See 
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=4077fb4d1d34ad04dfb95ba676c2b43ea1f1da53


cheers

andrew


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

Re: [HACKERS] controlling psql's use of the pager a bit more

[Andrew Dunstan]

On 11/13/2014 11:41 AM, Andrew Dunstan wrote:


On 11/13/2014 11:09 AM, Tom Lane wrote:

Andrew Dunstan and...@dunslane.net writes:
I often get annoyed because psql is a bit too aggressive when it 
decides

whether to put output through the pager, and the only way to avoid this
is to turn the pager off (in which case your next query might dump many
thousands of lines to the screen). I'd like a way to be able to specify
a minumum number of lines of output before psql would invoke the pager,
rather than just always using the terminal window size.

Are you saying you'd want to set the threshold to *more* than the window
height?  Why?



Because I might be quite happy with 100 or 200 lines I can just scroll 
in my terminal's scroll buffer, but want to use the pager for more 
than that. This is useful especially if I want to scroll back and see 
the results from a query or two ago.








This patch shows more or less what I had in mind.

However, there is more work to do. As Tom noted upthread, psql's 
calculation of the number of lines is pretty bad. For example, if I do:


   \pset pager_min_lines 100
   select * from generate_series(1,50);

the pager still gets invoked, which is unfortunate to say the least.

So I'm going to take a peek at that.

cheers

andrew

diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 26089352..b16149a 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -786,7 +786,7 @@ exec_command(const char *cmd,
 opt[--len] = '\0';
 		}
 
-		helpSQL(opt, pset.popt.topt.pager);
+		helpSQL(opt, pset.popt.topt.pager, pset.popt.topt.pager_min_lines);
 		free(opt);
 	}
 
@@ -1053,7 +1053,8 @@ exec_command(const char *cmd,
 			static const char *const my_list[] = {
 border, columns, expanded, fieldsep, fieldsep_zero,
 footer, format, linestyle, null,
-numericlocale, pager, recordsep, recordsep_zero,
+numericlocale, pager, pager_min_lines, 
+recordsep, recordsep_zero,
 tableattr, title, tuples_only,
 unicode_border_linestyle,
 unicode_column_linestyle,
@@ -1252,7 +1253,8 @@ exec_command(const char *cmd,
 	lines++;
 }
 
-output = PageOutput(lineno, pset.popt.topt.pager);
+output = PageOutput(lineno, pset.popt.topt.pager,
+	pset.popt.topt.pager_min_lines);
 is_pager = true;
 			}
 			else
@@ -1504,13 +1506,13 @@ exec_command(const char *cmd,
 	OT_NORMAL, NULL, false);
 
 		if (!opt0 || strcmp(opt0, commands) == 0)
-			slashUsage(pset.popt.topt.pager);
+			slashUsage(pset.popt.topt.pager, pset.popt.topt.pager_min_lines);
 		else if (strcmp(opt0, options) == 0)
-			usage(pset.popt.topt.pager);
+			usage(pset.popt.topt.pager, pset.popt.topt.pager_min_lines);
 		else if (strcmp(opt0, variables) == 0)
-			helpVariables(pset.popt.topt.pager);
+			helpVariables(pset.popt.topt.pager, pset.popt.topt.pager_min_lines);
 		else
-			slashUsage(pset.popt.topt.pager);
+			slashUsage(pset.popt.topt.pager, pset.popt.topt.pager_min_lines);
 	}
 
 #if 0
@@ -2506,6 +2508,13 @@ do_pset(const char *param, const char *value, printQueryOpt *popt, bool quiet)
 			popt-topt.pager = 1;
 	}
 
+	/* set minimum lines for pager use */
+	else if (strcmp(param, pager_min_lines) == 0)
+	{
+		if (value)
+			popt-topt.pager_min_lines = atoi(value);		
+	}
+
 	/* disable (x rows) footer */
 	else if (strcmp(param, footer) == 0)
 	{
@@ -2627,6 +2636,13 @@ printPsetInfo(const char *param, struct printQueryOpt *popt)
 			printf(_(Pager usage is off.\n));
 	}
 
+	/* show minimum lines for pager use */
+	else if (strcmp(param, pager_min_lines) == 0)
+	{
+		printf(_(Pager won't be used for less than %d lines\n),
+			   popt-topt.pager_min_lines);
+	}
+
 	/* show record separator for unaligned text */
 	else if (strcmp(param, recordsep) == 0)
 	{
@@ -2779,6 +2795,8 @@ pset_value_string(const char *param, struct printQueryOpt *popt)
 		return pstrdup(pset_bool_string(popt-topt.numericLocale));
 	else if (strcmp(param, pager) == 0)
 		return psprintf(%d, popt-topt.pager);
+	else if (strcmp(param, pager_min_lines) == 0)
+		return psprintf(%d, popt-topt.pager_min_lines);
 	else if (strcmp(param, recordsep) == 0)
 		return pset_quoted_string(popt-topt.recordSep.separator
   ? popt-topt.recordSep.separator
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
index 66d80b5..91102f4 100644
--- a/src/bin/psql/common.c
+++ b/src/bin/psql/common.c
@@ -1337,7 +1337,8 @@ ExecQueryUsingCursor(const char *query, double *elapsed_msec)
 			 * If query requires multiple result sets, hack to ensure that
 			 * only one pager instance is used for the whole mess
 			 */
-			pset.queryFout = PageOutput(10, my_popt.topt.pager);
+			pset.queryFout = PageOutput(10, my_popt.topt.pager,
+my_popt.topt.pager_min_lines);
 			did_pager = true;
 		}
 
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index ae5fe88..bb166b9 100644
--- a/src/bin/psql/help.c
+++ b/src/bin/psql/help.c
@@ -46,7 +46,7 @@
 #define ON(var) (var ? _(on) : _(off))
 
 

[HACKERS] controlling psql's use of the pager a bit more

[Andrew Dunstan]

I often get annoyed because psql is a bit too aggressive when it decides 
whether to put output through the pager, and the only way to avoid this 
is to turn the pager off (in which case your next query might dump many 
thousands of lines to the screen). I'd like a way to be able to specify 
a minumum number of lines of output before psql would invoke the pager, 
rather than just always using the terminal window size.


Thoughts?

cheers

andrew


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

Re: [HACKERS] controlling psql's use of the pager a bit more

[Thom Brown]

On 13 November 2014 15:52, Andrew Dunstan and...@dunslane.net wrote:


 I often get annoyed because psql is a bit too aggressive when it decides
 whether to put output through the pager, and the only way to avoid this is
 to turn the pager off (in which case your next query might dump many
 thousands of lines to the screen). I'd like a way to be able to specify a
 minumum number of lines of output before psql would invoke the pager,
 rather than just always using the terminal window size.


+1

I've found this annoying myself.
-- 
Thom

Re: [HACKERS] controlling psql's use of the pager a bit more

[Tom Lane]

Andrew Dunstan and...@dunslane.net writes:
 I often get annoyed because psql is a bit too aggressive when it decides 
 whether to put output through the pager, and the only way to avoid this 
 is to turn the pager off (in which case your next query might dump many 
 thousands of lines to the screen). I'd like a way to be able to specify 
 a minumum number of lines of output before psql would invoke the pager, 
 rather than just always using the terminal window size.

Are you saying you'd want to set the threshold to *more* than the window
height?  Why?

My impression is that the problem is not with the threshold as such,
it's that psql is not terribly careful about determining how many lines
it will put out (ie, the value being compared to the threshold isn't
100% reliable).  If that's correct, then a hand-set threshold isn't
really going to make you happier, and what's needed is some hard work
on improving the quality of the lines-to-be-output estimates.

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

Re: [HACKERS] controlling psql's use of the pager a bit more

[Andres Freund]

On 2014-11-13 11:09:06 -0500, Tom Lane wrote:
 Andrew Dunstan and...@dunslane.net writes:
  I often get annoyed because psql is a bit too aggressive when it decides 
  whether to put output through the pager, and the only way to avoid this 
  is to turn the pager off (in which case your next query might dump many 
  thousands of lines to the screen). I'd like a way to be able to specify 
  a minumum number of lines of output before psql would invoke the pager, 
  rather than just always using the terminal window size.
 
 Are you saying you'd want to set the threshold to *more* than the window
 height?  Why?

Not sure what that'd be useful for.

What I've noticed more than once is that it'd be useful to force the
pager if the result is wider than the screen.

 My impression is that the problem is not with the threshold as such,
 it's that psql is not terribly careful about determining how many lines
 it will put out (ie, the value being compared to the threshold isn't
 100% reliable).  If that's correct, then a hand-set threshold isn't
 really going to make you happier, and what's needed is some hard work
 on improving the quality of the lines-to-be-output estimates.

If it's that, I've personally solved that problem for me by adding -F
(aka --quit-if-one-screen) to $LESS.

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, 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

Re: [HACKERS] controlling psql's use of the pager a bit more

[Andrew Dunstan]

On 11/13/2014 11:09 AM, Tom Lane wrote:

Andrew Dunstan and...@dunslane.net writes:

I often get annoyed because psql is a bit too aggressive when it decides
whether to put output through the pager, and the only way to avoid this
is to turn the pager off (in which case your next query might dump many
thousands of lines to the screen). I'd like a way to be able to specify
a minumum number of lines of output before psql would invoke the pager,
rather than just always using the terminal window size.

Are you saying you'd want to set the threshold to *more* than the window
height?  Why?



Because I might be quite happy with 100 or 200 lines I can just scroll 
in my terminal's scroll buffer, but want to use the pager for more than 
that. This is useful especially if I want to scroll back and see the 
results from a query or two ago.




cheers

andrew


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

Re: [HACKERS] controlling psql's use of the pager a bit more

[Michael Banck]

On Thu, Nov 13, 2014 at 05:14:47PM +0100, Andres Freund wrote:
 On 2014-11-13 11:09:06 -0500, Tom Lane wrote:
  Andrew Dunstan and...@dunslane.net writes:
   I often get annoyed because psql is a bit too aggressive when it decides 
   whether to put output through the pager, and the only way to avoid this 
   is to turn the pager off (in which case your next query might dump many 
   thousands of lines to the screen). I'd like a way to be able to specify 
   a minumum number of lines of output before psql would invoke the pager, 
   rather than just always using the terminal window size.
  
  Are you saying you'd want to set the threshold to *more* than the window
  height?  Why?
 
 Not sure what that'd be useful for.
 
If the output is of the same order of magnitude as the window height, it
is still easy to compare the new output with whatever was above it by
conventional terminal scrolling (pgup, screen scrolling, whatever, if
present).  If a comparison is desired in the first place, that is.

If the output goes to the pager, you're stuck with it.  Unless of course
if the pager could somehow include the previous output up to some
threshold (while still being positioned at the beginning of the new
output in order to retain current behaviour), so one could scroll up in
the pager window.  That would rock.


Michael

-- 
Michael Banck
Tel.: +49 (0) 2161 / 4643-171 

credativ GmbH, HRB Mönchengladbach 12080 
Hohenzollernstr. 133, 41061 Mönchengladbach 
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer


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

Re: [HACKERS] controlling psql's use of the pager a bit more

[David G Johnston]

Andrew Dunstan wrote
 On 11/13/2014 11:09 AM, Tom Lane wrote:
 Andrew Dunstan lt;

 andrew@

 gt; writes:
 I often get annoyed because psql is a bit too aggressive when it decides
 whether to put output through the pager, and the only way to avoid this
 is to turn the pager off (in which case your next query might dump many
 thousands of lines to the screen). I'd like a way to be able to specify
 a minumum number of lines of output before psql would invoke the pager,
 rather than just always using the terminal window size.
 Are you saying you'd want to set the threshold to *more* than the window
 height?  Why?
 
 
 Because I might be quite happy with 100 or 200 lines I can just scroll 
 in my terminal's scroll buffer, but want to use the pager for more than 
 that. This is useful especially if I want to scroll back and see the 
 results from a query or two ago.

+1

David J.




--
View this message in context: 
http://postgresql.nabble.com/controlling-psql-s-use-of-the-pager-a-bit-more-tp5826819p5826833.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.


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

Re: [HACKERS] controlling psql's use of the pager a bit more

[Robert Haas]

On Thu, Nov 13, 2014 at 11:54 AM, David G Johnston
david.g.johns...@gmail.com wrote:
 Because I might be quite happy with 100 or 200 lines I can just scroll
 in my terminal's scroll buffer, but want to use the pager for more than
 that. This is useful especially if I want to scroll back and see the
 results from a query or two ago.

 +1

+1 from me, too.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Re: [HACKERS] controlling psql's use of the pager a bit more

[Merlin Moncure]

On Thu, Nov 13, 2014 at 11:39 AM, Robert Haas robertmh...@gmail.com wrote:
 On Thu, Nov 13, 2014 at 11:54 AM, David G Johnston
 david.g.johns...@gmail.com wrote:
 Because I might be quite happy with 100 or 200 lines I can just scroll
 in my terminal's scroll buffer, but want to use the pager for more than
 that. This is useful especially if I want to scroll back and see the
 results from a query or two ago.

 +1

 +1 from me, too.

me three (as long as the current behaviors are not messed with and the
new stuff is 'opt in' somehow -- I also use the force quit option to
less).

merlin


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

Re: [HACKERS] controlling psql's use of the pager a bit more

[David Johnston]

On Thu, Nov 13, 2014 at 10:55 AM, Merlin Moncure mmonc...@gmail.com wrote:

 On Thu, Nov 13, 2014 at 11:39 AM, Robert Haas robertmh...@gmail.com
 wrote:
  On Thu, Nov 13, 2014 at 11:54 AM, David G Johnston
  david.g.johns...@gmail.com wrote:
  Because I might be quite happy with 100 or 200 lines I can just scroll
  in my terminal's scroll buffer, but want to use the pager for more than
  that. This is useful especially if I want to scroll back and see the
  results from a query or two ago.
 
  +1
 
  +1 from me, too.

 me three (as long as the current behaviors are not messed with and the
 new stuff is 'opt in' somehow -- I also use the force quit option to
 less).



​Being able to use \pset pager​

​to toggle the capability seems useful.

Thus I'd suggest establishing a new pager_minlines​ option that if unset
(default) maintains the current behavior but which can have a value (0 to
int_max) where 0 ends up basically doing the same thing as always mode
for pager.  Leaving the value blank will cause the option to be unset
again and revert to the current behavior.

David J.

Re: [HACKERS] controlling psql's use of the pager a bit more

[Jeff Janes]

On Thu, Nov 13, 2014 at 7:52 AM, Andrew Dunstan and...@dunslane.net wrote:


 I often get annoyed because psql is a bit too aggressive when it decides
 whether to put output through the pager, and the only way to avoid this is
 to turn the pager off (in which case your next query might dump many
 thousands of lines to the screen). I'd like a way to be able to specify a
 minumum number of lines of output before psql would invoke the pager,
 rather than just always using the terminal window size.


+1.

If it scrolls 2 or 3 lines off the top, I can just use the scroll-back
buffer to look at them, I don't want the pager for that situation.

But I am more interested in width, not length.  I don't want it to switch
to the pager just because a couple lines would wrap, especially when
looking at EXPLAIN output.  I have played with changing \pset columns, but
then other things get screwy once you set that to a non-actual value.  I
don't recall of the top of my head which things those are, though.

Cheers,

Jeff

Re: [HACKERS] controlling psql's use of the pager a bit more

[Jeff Janes]

On Thu, Nov 13, 2014 at 8:14 AM, Andres Freund and...@2ndquadrant.com
wrote:

 On 2014-11-13 11:09:06 -0500, Tom Lane wrote:
  Andrew Dunstan and...@dunslane.net writes:
   I often get annoyed because psql is a bit too aggressive when it
 decides
   whether to put output through the pager, and the only way to avoid this
   is to turn the pager off (in which case your next query might dump many
   thousands of lines to the screen). I'd like a way to be able to specify
   a minumum number of lines of output before psql would invoke the pager,
   rather than just always using the terminal window size.
 
  Are you saying you'd want to set the threshold to *more* than the window
  height?  Why?

 Not sure what that'd be useful for.

 What I've noticed more than once is that it'd be useful to force the
 pager if the result is wider than the screen.


For which formats do you want that?  It is already done that way under
\pset format aligned.


Cheers,

Jeff

Re: [HACKERS] controlling psql's use of the pager a bit more

[Merlin Moncure]

On Thu, Nov 13, 2014 at 12:03 PM, David Johnston
david.g.johns...@gmail.com wrote:
 On Thu, Nov 13, 2014 at 10:55 AM, Merlin Moncure mmonc...@gmail.com wrote:

 On Thu, Nov 13, 2014 at 11:39 AM, Robert Haas robertmh...@gmail.com
 wrote:
  On Thu, Nov 13, 2014 at 11:54 AM, David G Johnston
  david.g.johns...@gmail.com wrote:
  Because I might be quite happy with 100 or 200 lines I can just scroll
  in my terminal's scroll buffer, but want to use the pager for more
  than
  that. This is useful especially if I want to scroll back and see the
  results from a query or two ago.
 
  +1
 
  +1 from me, too.

 me three (as long as the current behaviors are not messed with and the
 new stuff is 'opt in' somehow -- I also use the force quit option to
 less).



 Being able to use \pset pager

 to toggle the capability seems useful.

 Thus I'd suggest establishing a new pager_minlines option that if unset
 (default) maintains the current behavior but which can have a value (0 to
 int_max) where 0 ends up basically doing the same thing as always mode for
 pager.  Leaving the value blank will cause the option to be unset again
 and revert to the current behavior.

seems pretty reasonable.

merlin


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