psql \watch versus \timing

[Jeff Janes]

I'd like to run same query repeatedly and see how long it takes each time.

I thought \watch would be excellent for this, but it turns out that using
\watch suppresses the output of \timing.

Is this intentional, or unavoidable?

Also, is it just or does the inability to watch more frequently than once a
second make it a lot less useful than it could be?


Cheers,

Jeff

[Tom Lane]

Post by Jeff Janes
I'd like to run same query repeatedly and see how long it takes each time.
I thought \watch would be excellent for this, but it turns out that using
\watch suppresses the output of \timing.
Is this intentional, or unavoidable?

\watch uses PSQLexec not SendQuery; the latter implements \timing which
I agree is arguably useful here, but also autocommit/auto-savepoint
behavior which probably isn't a good idea.

It might be a good idea to refactor those two routines into one routine
with some sort of bitmap flags argument to control the various add-on
behaviors, but that seems like not 9.3 material anymore.

Post by Jeff Janes
Also, is it just or does the inability to watch more frequently than once a
second make it a lot less useful than it could be?

It did not seem that exciting to me. In particular, we've already found
out that \watch with zero delay is a pretty bad idea, so you'd have to
make a case for what smaller minimum to use if it's not to be 1 second.

regards, tom lane

[Fujii Masao]

Post by Tom Lane

Post by Jeff Janes
I'd like to run same query repeatedly and see how long it takes each time.
I thought \watch would be excellent for this, but it turns out that using
\watch suppresses the output of \timing.
Is this intentional, or unavoidable?

\watch uses PSQLexec not SendQuery; the latter implements \timing which
I agree is arguably useful here, but also autocommit/auto-savepoint
behavior which probably isn't a good idea.
It might be a good idea to refactor those two routines into one routine
with some sort of bitmap flags argument to control the various add-on
behaviors, but that seems like not 9.3 material anymore.

Attached patch changes \watch so that it displays how long the query takes
if \timing is enabled.

I didn't refactor PSQLexec and SendQuery into one routine because
the contents of those functions are not so same. I'm not sure how much
it's worth doing that refactoring. Anyway this feature is quite useful
even without that refactoring, I think.

BTW, I found that \watch doesn't check for async notifications. Is it useful
to allow \watch to do that? ISTM that it's not so bad idea to use \timing
to continuously check for async notifications. No?

Regards,

[Michael Paquier]

Post by Fujii Masao
Attached patch changes \watch so that it displays how long the query takes
if \timing is enabled.
I didn't refactor PSQLexec and SendQuery into one routine because
the contents of those functions are not so same. I'm not sure how much
it's worth doing that refactoring. Anyway this feature is quite useful
even without that refactoring, I think.

The patch applies correctly and it does correctly what it is made for:
=# \timing
Timing is on.
=# select 1;
?column?
----------
1
(1 row)
Time: 0.407 ms
=# \watch 1
Watch every 1s Mon Aug 18 15:17:41 2014
?column?
----------
1
(1 row)
Time: 0.397 ms
Watch every 1s Mon Aug 18 15:17:42 2014
?column?
----------
1
(1 row)
Time: 0.615 ms

Refactoring it would be worth it thinking long-term... And printing
the timing in PSQLexec code path is already done in SendQuery, so
that's doing two times the same thing IMHO.

Now, looking at the patch, introducing the new function
PSQLexecInternal with an additional parameter to control the timing is
correct choosing the non-refactoring way of doing. But I don't think
that printing the time outside PSQLexecInternal is consistent with
SendQuery. Why not simply control the timing with a boolean flag and
print the timing directly in PSQLexecInternal?
Regards,

[Fujii Masao]

On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier

Post by Michael Paquier

Post by Fujii Masao
Attached patch changes \watch so that it displays how long the query takes
if \timing is enabled.
I didn't refactor PSQLexec and SendQuery into one routine because
the contents of those functions are not so same. I'm not sure how much
it's worth doing that refactoring. Anyway this feature is quite useful
even without that refactoring, I think.

=# \timing
Timing is on.
=# select 1;
?column?
----------
1
(1 row)
Time: 0.407 ms
=# \watch 1
Watch every 1s Mon Aug 18 15:17:41 2014
?column?
----------
1
(1 row)
Time: 0.397 ms
Watch every 1s Mon Aug 18 15:17:42 2014
?column?
----------
1
(1 row)
Time: 0.615 ms
Refactoring it would be worth it thinking long-term... And printing
the timing in PSQLexec code path is already done in SendQuery, so
that's doing two times the same thing IMHO.
Now, looking at the patch, introducing the new function
PSQLexecInternal with an additional parameter to control the timing is
correct choosing the non-refactoring way of doing. But I don't think
that printing the time outside PSQLexecInternal is consistent with
SendQuery. Why not simply control the timing with a boolean flag and
print the timing directly in PSQLexecInternal?

Because the timing needs to be printed after the query result.

Regards,

[Michael Paquier]

Post by Fujii Masao
On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier

Post by Michael Paquier

Post by Fujii Masao
Attached patch changes \watch so that it displays how long the query takes
if \timing is enabled.
I didn't refactor PSQLexec and SendQuery into one routine because
the contents of those functions are not so same. I'm not sure how much
it's worth doing that refactoring. Anyway this feature is quite useful
even without that refactoring, I think.

=# \timing
Timing is on.
=# select 1;
?column?
----------
1
(1 row)
Time: 0.407 ms
=# \watch 1
Watch every 1s Mon Aug 18 15:17:41 2014
?column?
----------
1
(1 row)
Time: 0.397 ms
Watch every 1s Mon Aug 18 15:17:42 2014
?column?
----------
1
(1 row)
Time: 0.615 ms
Refactoring it would be worth it thinking long-term... And printing
the timing in PSQLexec code path is already done in SendQuery, so
that's doing two times the same thing IMHO.
Now, looking at the patch, introducing the new function
PSQLexecInternal with an additional parameter to control the timing is
correct choosing the non-refactoring way of doing. But I don't think
that printing the time outside PSQLexecInternal is consistent with
SendQuery. Why not simply control the timing with a boolean flag and
print the timing directly in PSQLexecInternal?

Because the timing needs to be printed after the query result.

Thanks for pointing that. Yes this makes the refactoring a bit more difficult.

[Heikki Linnakangas]

Post by Michael Paquier

Post by Fujii Masao
On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier

Post by Michael Paquier

Post by Fujii Masao
Attached patch changes \watch so that it displays how long the query takes
if \timing is enabled.
I didn't refactor PSQLexec and SendQuery into one routine because
the contents of those functions are not so same. I'm not sure how much
it's worth doing that refactoring. Anyway this feature is quite useful
even without that refactoring, I think.

=# \timing
Timing is on.
=# select 1;
?column?
----------
1
(1 row)
Time: 0.407 ms
=# \watch 1
Watch every 1s Mon Aug 18 15:17:41 2014
?column?
----------
1
(1 row)
Time: 0.397 ms
Watch every 1s Mon Aug 18 15:17:42 2014
?column?
----------
1
(1 row)
Time: 0.615 ms
Refactoring it would be worth it thinking long-term... And printing
the timing in PSQLexec code path is already done in SendQuery, so
that's doing two times the same thing IMHO.
Now, looking at the patch, introducing the new function
PSQLexecInternal with an additional parameter to control the timing is
correct choosing the non-refactoring way of doing. But I don't think
that printing the time outside PSQLexecInternal is consistent with
SendQuery. Why not simply control the timing with a boolean flag and
print the timing directly in PSQLexecInternal?

Because the timing needs to be printed after the query result.

Thanks for pointing that. Yes this makes the refactoring a bit more difficult.

Michael reviewed this, so I'm marking this as Ready for Committer. Since
you're a committer yourself, I expect you'll take it over from here.

I agree that refactoring this would be nice in the long-term, and I also
agree that it's probably OK as it is in the short-term. I don't like the
name PSQLexecInternal, though. PSQLexec is used for "internal" commands
anyway. In fact it's backwards, because PSQLexecInternal is used for
non-internal queries, given by \watch, while PSQLexec is used for
internal commands.

- Heikki

[Fujii Masao]

On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas

Post by Heikki Linnakangas

Post by Michael Paquier

Post by Fujii Masao
On Mon, Aug 18, 2014 at 3:19 PM, Michael Paquier

Post by Michael Paquier

Post by Fujii Masao
Attached patch changes \watch so that it displays how long the query takes
if \timing is enabled.
I didn't refactor PSQLexec and SendQuery into one routine because
the contents of those functions are not so same. I'm not sure how much
it's worth doing that refactoring. Anyway this feature is quite useful
even without that refactoring, I think.

=# \timing
Timing is on.
=# select 1;
?column?
----------
1
(1 row)
Time: 0.407 ms
=# \watch 1
Watch every 1s Mon Aug 18 15:17:41 2014
?column?
----------
1
(1 row)
Time: 0.397 ms
Watch every 1s Mon Aug 18 15:17:42 2014
?column?
----------
1
(1 row)
Time: 0.615 ms
Refactoring it would be worth it thinking long-term... And printing
the timing in PSQLexec code path is already done in SendQuery, so
that's doing two times the same thing IMHO.
Now, looking at the patch, introducing the new function
PSQLexecInternal with an additional parameter to control the timing is
correct choosing the non-refactoring way of doing. But I don't think
that printing the time outside PSQLexecInternal is consistent with
SendQuery. Why not simply control the timing with a boolean flag and
print the timing directly in PSQLexecInternal?

Because the timing needs to be printed after the query result.

Thanks for pointing that. Yes this makes the refactoring a bit more difficult.

Michael reviewed this, so I'm marking this as Ready for Committer. Since
you're a committer yourself, I expect you'll take it over from here.

Yep!

Post by Heikki Linnakangas
I agree that refactoring this would be nice in the long-term, and I also
agree that it's probably OK as it is in the short-term. I don't like the
name PSQLexecInternal, though. PSQLexec is used for "internal" commands
anyway. In fact it's backwards, because PSQLexecInternal is used for
non-internal queries, given by \watch, while PSQLexec is used for internal
commands.

Agreed. So what about PSQLexecCommon (inspired by
the relation between LWLockAcquireCommon and LWLockAcquire)?
Or any better name?

Regards,

[Heikki Linnakangas]

Post by Fujii Masao
On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas

Post by Heikki Linnakangas
I agree that refactoring this would be nice in the long-term, and I also
agree that it's probably OK as it is in the short-term. I don't like the
name PSQLexecInternal, though. PSQLexec is used for "internal" commands
anyway. In fact it's backwards, because PSQLexecInternal is used for
non-internal queries, given by \watch, while PSQLexec is used for internal
commands.

Agreed. So what about PSQLexecCommon (inspired by
the relation between LWLockAcquireCommon and LWLockAcquire)?
Or any better name?

Actually, perhaps it would be better to just copy-paste PSQLexec, and
modify the copy to suite \watch's needs. (PSQLexecWatch?
SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
overlap between what \watch wants and what other PSQLexec callers want.
\watch wants timing output, others don't. \watch doesn't want
transaction handling. Do we want --echo-hidden to print the \watch'd
query? Not sure..

- Heikki

[Heikki Linnakangas]

Post by Heikki Linnakangas

Post by Fujii Masao
On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas

Post by Heikki Linnakangas
I agree that refactoring this would be nice in the long-term, and I also
agree that it's probably OK as it is in the short-term. I don't like the
name PSQLexecInternal, though. PSQLexec is used for "internal" commands
anyway. In fact it's backwards, because PSQLexecInternal is used for
non-internal queries, given by \watch, while PSQLexec is used for internal
commands.

Agreed. So what about PSQLexecCommon (inspired by
the relation between LWLockAcquireCommon and LWLockAcquire)?
Or any better name?

Actually, perhaps it would be better to just copy-paste PSQLexec, and
modify the copy to suite \watch's needs. (PSQLexecWatch?
SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
overlap between what \watch wants and what other PSQLexec callers want.
\watch wants timing output, others don't. \watch doesn't want
transaction handling. Do we want --echo-hidden to print the \watch'd
query? Not sure..

BTW, I just noticed that none of the callers of PSQLexec pass
"start_xact=true". So that part of the function is dead code. We might
want to remove it, and replace with a comment noting that PSQLexec never
starts a new transaction block, even in autocommit-off mode. (I know
you're hacking on this, so I didnn't want to joggle your elbow by doing
it right now)

- Heikki

[Fujii Masao]

On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas

Post by Heikki Linnakangas

Post by Heikki Linnakangas

Post by Fujii Masao
On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas

Post by Heikki Linnakangas
I agree that refactoring this would be nice in the long-term, and I also
agree that it's probably OK as it is in the short-term. I don't like the
name PSQLexecInternal, though. PSQLexec is used for "internal" commands
anyway. In fact it's backwards, because PSQLexecInternal is used for
non-internal queries, given by \watch, while PSQLexec is used for internal
commands.

Agreed. So what about PSQLexecCommon (inspired by
the relation between LWLockAcquireCommon and LWLockAcquire)?
Or any better name?

Actually, perhaps it would be better to just copy-paste PSQLexec, and
modify the copy to suite \watch's needs. (PSQLexecWatch?
SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
overlap between what \watch wants and what other PSQLexec callers want.
\watch wants timing output, others don't. \watch doesn't want
transaction handling.

Agreed. Attached is the revised version of the patch. I implemented
PSQLexecWatch() which sends the query, prints the results and outputs
the query execution time (if \timing is enabled).

This patch was marked as ready for committer, but since I revised
the code very much, I marked this as needs review again.

Post by Heikki Linnakangas

Post by Heikki Linnakangas
Do we want --echo-hidden to print the \watch'd
query? Not sure..

Per document, --echo-hidden prints the actual queries generated by
backslash command. But \watch doesn't handle backslash commands.
So I think that PSQLexecWatch doesn't need to handle --echo-hidden.

Post by Heikki Linnakangas
BTW, I just noticed that none of the callers of PSQLexec pass
"start_xact=true". So that part of the function is dead code. We might want
to remove it, and replace with a comment noting that PSQLexec never starts a
new transaction block, even in autocommit-off mode. (I know you're hacking
on this, so I didnn't want to joggle your elbow by doing it right now)

Good catch. So I will remove start_xact code later.

Regards,

[Heikki Linnakangas]

Post by Fujii Masao
On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas

Post by Heikki Linnakangas
Actually, perhaps it would be better to just copy-paste PSQLexec, and
modify the copy to suite \watch's needs. (PSQLexecWatch?
SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
overlap between what \watch wants and what other PSQLexec callers want.
\watch wants timing output, others don't. \watch doesn't want
transaction handling.

Agreed. Attached is the revised version of the patch. I implemented
PSQLexecWatch() which sends the query, prints the results and outputs
the query execution time (if \timing is enabled).
This patch was marked as ready for committer, but since I revised
the code very much, I marked this as needs review again.
... We use PSQLexecWatch,
! * which is kind of cheating, but SendQuery doesn't let us suppress
! * autocommit behavior.

is a bit strange now. PSQLexecWatch isn't cheating like reusing PSQLexec
was; it's whole purpose is to run \watch queries.

Post by Fujii Masao
/*
* Set up cancellation of 'watch' via SIGINT. We redo this each time
* through the loop since it's conceivable something inside PSQLexec
* could change sigint_interrupt_jmp.
*/

This should now say "PSQLexecWatch".

Other than that, looks good to me.

- Heikki

[Michael Paquier]

On Fri, Aug 29, 2014 at 6:33 PM, Heikki Linnakangas

Post by Heikki Linnakangas

Post by Fujii Masao
On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas

Post by Heikki Linnakangas
Actually, perhaps it would be better to just copy-paste PSQLexec, and
modify the copy to suite \watch's needs. (PSQLexecWatch?
SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
overlap between what \watch wants and what other PSQLexec callers want.
\watch wants timing output, others don't. \watch doesn't want
transaction handling.

Agreed. Attached is the revised version of the patch. I implemented
PSQLexecWatch() which sends the query, prints the results and outputs
the query execution time (if \timing is enabled).
This patch was marked as ready for committer, but since I revised
the code very much, I marked this as needs review again.
... We use PSQLexecWatch,
! * which is kind of cheating, but SendQuery doesn't let us
suppress
! * autocommit behavior.

is a bit strange now. PSQLexecWatch isn't cheating like reusing PSQLexec
was; it's whole purpose is to run \watch queries.

Post by Fujii Masao
/*
* Set up cancellation of 'watch' via SIGINT. We redo this each time
* through the loop since it's conceivable something inside PSQLexec
* could change sigint_interrupt_jmp.
*/

This should now say "PSQLexecWatch".
Other than that, looks good to me.

I just tested the patch and this feature works as expected if timing
is on and it displays the individual run time of each query kicked by
\watch. Note that --echo-hidden does not display the query run during
each loop and that this is contrary to the behavior in HEAD so it
breaks backward compatibility, but are there really people relying in
the existing behavior?

[Tom Lane]

Post by Michael Paquier
I just tested the patch and this feature works as expected if timing
is on and it displays the individual run time of each query kicked by
\watch. Note that --echo-hidden does not display the query run during
each loop and that this is contrary to the behavior in HEAD so it
breaks backward compatibility, but are there really people relying in
the existing behavior?

ISTM that's an anti-feature anyway, and changing that behavior is a
good thing.

regards, tom lane

[Michael Paquier]

Post by Tom Lane

Post by Michael Paquier
I just tested the patch and this feature works as expected if timing
is on and it displays the individual run time of each query kicked by
\watch. Note that --echo-hidden does not display the query run during
each loop and that this is contrary to the behavior in HEAD so it
breaks backward compatibility, but are there really people relying in
the existing behavior?

ISTM that's an anti-feature anyway, and changing that behavior is a
good thing.

OK, then as all the comments are basically addressed, here is an
updated patch correcting the comment problems mentioned by Heikki.
This is ready for a committer.
Regards,

[Greg Stark]

On Wed, Sep 3, 2014 at 12:48 PM, Michael Paquier

Post by Michael Paquier
OK, then as all the comments are basically addressed, here is an
updated patch correcting the comment problems mentioned by Heikki.

I just tried this and found it doesn't cooperate well with AUTOCOMMIT
= 'off' and ON_ERROR_ROLLBACK = 'on'. Previously \watch would leave
the transaction in a normal state after C-c but now it leaves the
transaction in an aborted state. I assume it previously did a
savepoint around each execution and now it's not doing that at all.

[Fujii Masao]

Post by Greg Stark
On Wed, Sep 3, 2014 at 12:48 PM, Michael Paquier

Post by Michael Paquier
OK, then as all the comments are basically addressed, here is an
updated patch correcting the comment problems mentioned by Heikki.

Thanks a lot!

Post by Greg Stark
I just tried this and found it doesn't cooperate well with AUTOCOMMIT
= 'off' and ON_ERROR_ROLLBACK = 'on'. Previously \watch would leave
the transaction in a normal state after C-c but now it leaves the
transaction in an aborted state. I assume it previously did a
savepoint around each execution and now it's not doing that at all.

No. Previously \watch used PSQLexec and it doesn't use savepoint.
If you enter Ctrl-C while \watch is waiting for the query to end,
\watch would leave the transaction in an aborted state whether
the patch has been applied or not. OTOH, if you enter Ctrl-C while
\watch is sleeping, the transaction remains in normal state.

Regards,

[Fujii Masao]

Post by Fujii Masao

Post by Greg Stark
On Wed, Sep 3, 2014 at 12:48 PM, Michael Paquier

Post by Michael Paquier
OK, then as all the comments are basically addressed, here is an
updated patch correcting the comment problems mentioned by Heikki.

Thanks a lot!

Applied. Thanks all!

Regards,

[Fujii Masao]

Post by Fujii Masao
On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas

Post by Heikki Linnakangas

Post by Heikki Linnakangas

Post by Fujii Masao
On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas

Post by Heikki Linnakangas
I agree that refactoring this would be nice in the long-term, and I also
agree that it's probably OK as it is in the short-term. I don't like the
name PSQLexecInternal, though. PSQLexec is used for "internal" commands
anyway. In fact it's backwards, because PSQLexecInternal is used for
non-internal queries, given by \watch, while PSQLexec is used for internal
commands.

Agreed. So what about PSQLexecCommon (inspired by
the relation between LWLockAcquireCommon and LWLockAcquire)?
Or any better name?

Actually, perhaps it would be better to just copy-paste PSQLexec, and
modify the copy to suite \watch's needs. (PSQLexecWatch?
SendWatchQuery?). PSQLexec doesn't do much, and there isn't very much
overlap between what \watch wants and what other PSQLexec callers want.
\watch wants timing output, others don't. \watch doesn't want
transaction handling.

Agreed. Attached is the revised version of the patch. I implemented
PSQLexecWatch() which sends the query, prints the results and outputs
the query execution time (if \timing is enabled).
This patch was marked as ready for committer, but since I revised
the code very much, I marked this as needs review again.

Post by Heikki Linnakangas

Post by Heikki Linnakangas
Do we want --echo-hidden to print the \watch'd
query? Not sure..

Per document, --echo-hidden prints the actual queries generated by
backslash command. But \watch doesn't handle backslash commands.
So I think that PSQLexecWatch doesn't need to handle --echo-hidden.

Post by Heikki Linnakangas
BTW, I just noticed that none of the callers of PSQLexec pass
"start_xact=true". So that part of the function is dead code. We might want
to remove it, and replace with a comment noting that PSQLexec never starts a
new transaction block, even in autocommit-off mode. (I know you're hacking
on this, so I didnn't want to joggle your elbow by doing it right now)

Good catch. So I will remove start_xact code later.

Attached patch removes start_xact from PSQLexec.

Regards,

[Michael Paquier]

Post by Fujii Masao

Post by Fujii Masao
Good catch. So I will remove start_xact code later.

Attached patch removes start_xact from PSQLexec.

Nothing negative to say here :)
Patch simply removes the second argument of PSQLexec that was set to
the same value everywhere, aka false as noticed by Heikki. Comments
and code blocks related to this parameter are removed, and the code
compiles, passing check-world as well (just kicked the tests in case).
Regards,

[Bruce Momjian]

Post by Michael Paquier

Post by Fujii Masao

Post by Fujii Masao
Good catch. So I will remove start_xact code later.

Attached patch removes start_xact from PSQLexec.

Nothing negative to say here :)
Patch simply removes the second argument of PSQLexec that was set to
the same value everywhere, aka false as noticed by Heikki. Comments
and code blocks related to this parameter are removed, and the code
compiles, passing check-world as well (just kicked the tests in case).

Uh, where are we on this? Should I commit it?
--
Bruce Momjian <***@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

[Michael Paquier]

Post by Bruce Momjian

Post by Michael Paquier

Post by Fujii Masao

Post by Fujii Masao
Good catch. So I will remove start_xact code later.

Attached patch removes start_xact from PSQLexec.

Nothing negative to say here :)
Patch simply removes the second argument of PSQLexec that was set to
the same value everywhere, aka false as noticed by Heikki. Comments
and code blocks related to this parameter are removed, and the code
compiles, passing check-world as well (just kicked the tests in case).

Uh, where are we on this? Should I commit it?

The patch cleaning up the dead code of psql could be clearly applied
now. For the feature itself not sure, it may be better to let
Fujii-san manage it.

[Fujii Masao]

On Tue, Oct 14, 2014 at 8:11 AM, Michael Paquier

Post by Michael Paquier

Post by Bruce Momjian

Post by Michael Paquier

Post by Fujii Masao

Post by Fujii Masao
Good catch. So I will remove start_xact code later.

Attached patch removes start_xact from PSQLexec.

Nothing negative to say here :)
Patch simply removes the second argument of PSQLexec that was set to
the same value everywhere, aka false as noticed by Heikki. Comments
and code blocks related to this parameter are removed, and the code
compiles, passing check-world as well (just kicked the tests in case).

Uh, where are we on this? Should I commit it?

The patch cleaning up the dead code of psql could be clearly applied
now. For the feature itself not sure, it may be better to let
Fujii-san manage it.

Applied.

Regards,