Re: Log timestamps at higher resolution

On Wed, Oct 24, 2018 at 11:10:02AM +0100, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
> > On Wed, Oct 24, 2018 at 08:00:24AM +1300, Thomas Munro wrote:
> >> On Wed, Oct 24, 2018 at 7:51 AM David Fetter <david(at)fetter(dot)org> wrote:
> >>> Per gripes I've been hearing with increasing frequency, please find
> >>> attached a patch that implements $Subject. It's microsecond resolution
> >>> because at least at the moment, nanosecond resolution doesn't appear
> >>> to be helpful in this context.
>
> >> Wouldn't you want to choose a new letter or some other way to make
> >> existing format control strings do what they always did?
>
> > I hadn't because I'd looked at the existing format as merely buggy in
> > lacking precision, although I guess with really fussy log processors,
> > this change could break things.
>
> Aside from breaking things, this would increase log volume, which is
> already a pain point for many people.

As to log volume, this may or may not be in our ambit to address.
There are Linux distros that "handle" this by automatically using
compression so slow that it completely tanks performance, as in
shrinks TPS by an order of magnitude or more. For me, the
lesson there is to make those trade-offs explicit and controllable by
our users rather than magically imposed by whatever means.

> So I think your odds of getting it committed as-is are nil. It
> might be OK as a different letter, or with some other way of
> controlling the precision.

Would you be OK with a way to control the precision that defaults to
more precise and comes with a big loud release note about how to get
the previous behavior?

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate