Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
От | Robert Haas |
---|---|
Тема | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
Дата | |
Msg-id | CA+TgmoYOvh=k-H9m21Lh-SWbn7TNurm3JoOVxW+kOO=Gn1_8Xw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
|
Список | pgsql-hackers |
On Fri, Jan 13, 2023 at 2:56 PM Andres Freund <andres@anarazel.de> wrote: > Does anybody see a reason to not move forward with this aspect? We do a fair > amount of INSTR_TIME_ACCUM_DIFF() etc, and that gets a good bit cheaper by > just using nanoseconds. We'd also save memory in BufferUsage (144-122 bytes), > Instrumentation (16 bytes saved in Instrumentation itself, 32 via > BufferUsage). I read through 0001 and it seems basically fine to me. Comments: 1. pg_clock_gettime_ns() doesn't follow pgindent conventions. 2. I'm not entirely sure that the new .?S_PER_.?S macros are worthwhile but maybe they are, and in any case I don't care very much. 3. I've always found 'struct timespec' to be pretty annoying notationally, so I like the fact that this patch would reduce use of it. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: