Em qua., 12 de jun. de 2024 às 14:53, Tom Lane <t...@sss.pgh.pa.us> escreveu:
> Robert Haas <robertmh...@gmail.com> writes: > > I agree this is not great. I guess I didn't think about it very hard > > because, after all, we were just exposing an API that we'd already > > been using internally. But I think it's reasonable to adjust the API > > to allow for better resolution, as you propose. A second is a very > > long amount of time, and it's entirely reasonable for someone to want > > better granularity. > > Here's a v2 responding to some of the comments. > > * People pushed back against not using "int64", but the difficulty > with that is that we'd have to #include c.h or at least pg_config.h > in libpq-fe.h, and that would be a totally disastrous invasion of > application namespace. However, I'd forgotten that libpq-fe.h > does include postgres_ext.h, and there's just enough configure > infrastructure behind that to allow defining pg_int64, which indeed > libpq-fe.h is already relying on. So we can use that. > > * I decided to invent a typedef > > typedef pg_int64 PGusec_time_t; > Perhaps pg_timeusec? I think it combines with PQgetCurrentTimeUSec > > instead of writing "pg_int64" explicitly everywhere. This is perhaps > not as useful as it was when I was thinking the definition would be > "long long int", but it still seems to add some readability. In my > eyes anyway ... anyone think differently? > > * I also undid changes like s/end_time/end_time_us/. I'd done that > mostly to ensure I looked at/fixed every reference to those variables, > but on reflection I don't think it's doing anything for readability. > end_time seems much better to me. > > * I took Ranier's suggestion to make fast paths for end_time == 0. > I'm not sure this will make any visible performance difference, but > it's simple and shouldn't hurt. We do have some code paths that use > that behavior. > Thanks. > > * Ranier also suggested using clock_gettime instead of gettimeofday, > but I see no reason to do that. libpq already relies on gettimeofday, > but not on clock_gettime, and anyway post-beta1 isn't a great time to > start experimenting with portability-relevant changes. > I agree. For v18, it would be a case of thinking about not using it anymore gettimeofday, as it appears to be deprecated. best regards, Ranier Vilela
