Re: What is a typical precision of gettimeofday()?
От | Hannu Krosing |
---|---|
Тема | Re: What is a typical precision of gettimeofday()? |
Дата | |
Msg-id | CAMT0RQT9tbJgQ8NKqNowBbd=RRcMjM50Q9wSb_eGiX6VibyG0w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: What is a typical precision of gettimeofday()? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mon, Jul 7, 2025 at 11:38 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > Also added a flag to select number of direct values to show > > Hmm ... I agree with having a way to control the length of that output, > but I don't think that specifying a count is the most useful way to > do it. Particularly with a default of only 10, it seems way too > likely to cut off important information. > > What do you think of instead specifying the limit as the maximum > running-percentage to print, with a default of say 99.99%? That > gives me results like I agree that percentage covered is a much better metric indeed. And I am equally ok with a default of either 99.9% or 99.99%. I briefly thought of it but decided a simple count is simpler to explain, especially for some potential corner cases of % . But as pg_test_timing is not part of the server we really do not need to worry about rare edge cases. > Observed timing durations up to 99.9900%: > ns % of total running % count > 15 4.5452 4.5452 8313178 > 16 58.3785 62.9237 106773354 > 17 33.6840 96.6078 61607584 > 18 3.1151 99.7229 5697480 > 19 0.2638 99.9867 482570 > 20 0.0093 99.9960 17054 > > In the attached I also made it print the largest observed > duration, which seems like it might be useful information. Yes, a useful piece of information indeed. > As previously threatened, I also added a test case to > improve the code coverage. Thanks!
В списке pgsql-hackers по дате отправления: