Thread: Re: Allow default \watch interval in psql to be configured

Re: Allow default \watch interval in psql to be configured

From
Heikki Linnakangas
Date:
On 09/10/2024 16:08, Daniel Gustafsson wrote:
> Scratching an old itch; I've long wanted to be able to set the default interval
> for \watch in psql since I almost never want a 2 second wait.  The interval can
> of course be set by passing it to \watch but it's handy during testing and
> debugging to save that with just quick \watch.
> 
> The attached adds a new variable, WATCH_INTERVAL, which is used as the default
> value in case no value is defined when executing the command.  The defualt of
> this remains at 2 seconds as it is now.  The count and min_rows values are not
> affected by this as those seem less meaningful to set defaults on.

../src/bin/psql/startup.c:953:80: error: too many arguments to function 
call, expected 4, have 5
         return ParseVariableDouble(newval, "WATCH_INTERVAL", 
&pset.watch_interval, 0, 1000);
                ~~~~~~~~~~~~~~~~~~~ 
               ^~~~
../src/bin/psql/variables.h:84:7: note: 'ParseVariableDouble' declared here
bool            ParseVariableDouble(const char *value, const char *name,
                 ^
1 error generated.

I guess the '1000' was supposed to be the maximum, but 
ParseVariableDouble doesn't take a maximum.

After fixing that by removing the '1000' argument:


postgres=# \set WATCH_INTERVAL -10
invalid value "-10" for "WATCH_INTERVAL": must be greater than 0.00

That's a little inaccurate: 0 is also accepted, so should be "must be 
greater than *or equal to* 0". Or maybe "cannot be negative". -0 is also 
accepted, though.

> +        This variable set the default interval which <command>\watch</command>

set -> sets

> +       HELP0("  WATCH_INTERVAL\n"
> +                 "    number of seconds \\watch waits beetween queries\n");

beetween -> between

-- 
Heikki Linnakangas
Neon (https://neon.tech)




Re: Allow default \watch interval in psql to be configured

From
Pavel Stehule
Date:


čt 10. 10. 2024 v 2:02 odesílatel Michael Paquier <michael@paquier.xyz> napsal:
On Wed, Oct 09, 2024 at 04:24:27PM +0200, Daniel Gustafsson wrote:
> Fixed.

-        double        sleep = 2;
+        double        sleep = pset.watch_interval;

This forces the use of seconds as unit.  The interval values I have
been using a lot myself are between 0.2s and 0.5s because I usually
want a lot more granularity in my lookups than the 1s interval.  Could
it be better to allow values lower than 1s or let this value be a
string with optional "s" or "ms" units?

Linux "watch" uses just seconds. If I remember correctly the psql doesn't use units in settings, so I prefer just the value from interval 0.1 .. 3600 * n

and the number can be rounded to 0.1

Regards

Pavel

 
--
Michael

Re: Allow default \watch interval in psql to be configured

From
Daniel Gustafsson
Date:
> On 10 Oct 2024, at 02:01, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Oct 09, 2024 at 04:24:27PM +0200, Daniel Gustafsson wrote:
>> Fixed.
>
> -        double        sleep = 2;
> +        double        sleep = pset.watch_interval;
>
> This forces the use of seconds as unit.  The interval values I have
> been using a lot myself are between 0.2s and 0.5s because I usually
> want a lot more granularity in my lookups than the 1s interval.  Could
> it be better to allow values lower than 1s or let this value be a
> string with optional "s" or "ms" units?

I'm not sure I follow, it's true that the unit is seconds but the patch doesn't
change the ability to use fractions of a second that we already support today.

db=# \echo :WATCH_INTERVAL
2
db=# \set WATCH_INTERVAL 0.1
db=# \echo :WATCH_INTERVAL
0.1
db=# select 1;
 ?column?
----------
        1
(1 row)

danielg=# \watch
Thu Oct 10 09:32:05 2024 (every 0.1s)

 ?column?
----------
        1
(1 row)

Thu Oct 10 09:32:05 2024 (every 0.1s)

 ?column?
----------
        1
(1 row)

Or did I misunderstand your email?

We could support passing in an optional unit, and assume the unit to be seconds
if none was used, but it doesn't really fit nicely with the current API we have
so I wonder if the added complexity is worth it?

--
Daniel Gustafsson