Re: proposal: rounding up time value less than its unit.

Tom Lane-2 wrote
> Robert Haas <

> robertmhaas@

> > writes:
>> I liked David Johnston's even stronger suggestion upthread: make it an
>> error to specify a value requires rounding of any kind.  In other
>> words, if the minimum granularity is 1 minute, you can specify that as
>> 60 seconds instead, but if you write 59 seconds, we error out.  Maybe
>> that seems pedantic, but I don't think users will much appreciate the
>> discovery that 30 seconds means 60 seconds.  They'll be happier to be
>> told that up front than having to work it out afterward.
>
> I think this is totally wrong.  The entire point of the GUC units system,
> or at least a large part of the point, is that users should not have to
> be intimately aware of the units in which a given value is measured
> internally.  And that in turn means that the units had better be such
> that users won't find them overly coarse.  If it matters a lot whether
> 59 seconds gets rounded to 60, then we didn't make a good choice of units
> for the GUC in question; and we should fix that choice, not mess with the
> rounding rules.
>
> The case where this argument falls down is for "special" values, such as
> where zero means something quite different from the smallest nonzero
> value.  Peter suggested upthread that we should redefine any GUC values
> for which that is true, but (a) I think that loses on backwards
> compatibility grounds, and (b) ISTM zero is probably always special to
> some extent.  A zero time delay for example is not likely to work.
>
> Maybe we should leave the rounding behavior alone (there's not much
> evidence that rounding in one direction is worse than another; although
> I'd also be okay with changing to round-to-nearest), and confine ourselves
> to throwing an error for the single case that an apparently nonzero input
> value is truncated/rounded to zero as a result of units conversion.

To Andres' point:

SELECT unit, count(*) FROM pg_settings WHERE unit <> '' GROUP BY unit; (9.3
/ Ubuntu)

min (1 - log_rotation_age)
s (10)
ms (13)

kb (7)
8kb (6)

I don't know about the size implications but they seem to be non-existent.
That any setting critically matters at +/- 1s or 1ms doesn't seem likely in
practice.  Even +/- 1min for a setting, if it did matter at extreme scale,
would be recognizable by the user in practice as a rounding artifact and
compensated for.

At this point throwing an error for any precision that results in less than
the default precision is my preference.  I would not change the rounding
rules for the simple reason that there is no obvious improvement to be had
and so why introduce pointless change that - however marginal and unlikely -
will be user-visible.

The complaint to overcome is avoiding an interpretation of "zero" when the
precision of the input is less than the GUC unit.  Lacking any concrete
complaints about our round-down policy I don't see where a change there is
worthwhile.

Fixing zero as a special value falls under the same category. As
mathematically pure as using infinity may be the trade-off for practicality
and usability seems, even in light of this complaint, like the correct one
to have made.

David J.








--
View this message in context: http://postgresql.1045698.n5.nabble.com/proposal-rounding-up-time-value-less-than-its-unit-tp5811102p5816409.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