Re: Add LSN <-> time conversion functionality

On 8/9/24 15:09, Melanie Plageman wrote:
>
> ...
>
> Okay, so as I think about evaluating a few new algorithms, I realize
> that we do need some sort of criteria. I started listing out what I
> feel is "reasonable" accuracy and plotting it to see if the
> relationship is linear/exponential/etc. I think it would help to get
> input on what would be "reasonable" accuracy.
>
> I thought that the following might be acceptable:
> The first column is how old the value I am looking for actually is,
> the second column is how off I am willing to have the algorithm tell
> me it is (+/-):
>
> 1 second, 1 minute
> 1 minute, 10 minute
> 1 hour, 1 hour
> 1 day, 6 hours
> 1 week, 12 hours
> 1 month, 1 day
> 6 months, 1 week
>

I think the question is whether we want to make this useful for other
places and/or people, or if it's fine to tailor this specifically for
the freezing patch.

If the latter (specific to the freezing patch), I don't see why would it
matter what we think - either it works for the patch, or not.

But if we want to make it more widely useful, I find it a bit strange
the relative accuracy *increases* for older data. I mean, we start with
relative error 6000% (60s/1s) and then we get to relative error ~4%
(1w/24w). Isn't that a bit against the earlier discussion on needing
better accuracy for recent data? Sure, the absolute accuracy is still
better (1m <<< 1w). And if this is good enough for the freezing ...

> Column 1 over column 2 produces a line like in the attached pic. I'd
> be interested in others' opinions of error tolerance.
>
> - Melanie

I don't understand what the axes on the chart are :-( Does "A over B"
mean A is x-axis or y-axis?

--
Tomas Vondra