Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
От | Andres Freund |
---|---|
Тема | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
Дата | |
Msg-id | 20230207181218.47irz3of34qsww5l@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? (David Geier <geidav.pg@gmail.com>) |
Ответы |
Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
|
Список | pgsql-hackers |
Hi, On 2023-01-24 14:30:34 +0100, David Geier wrote: > Attached is v7 of the patch: > > - Rebased on latest master (most importantly on top of the int64 instr_time > commits). - Includes two commits from Andres which introduce > INSTR_TIME_SET_SECONDS(), INSTR_TIME_IS_LT() and WIP to report > pg_test_timing output in nanoseconds. - Converts ticks to nanoseconds only > with integer math, while accounting for overflow. - Supports RDTSCP via > INSTR_TIME_SET_CURRENT() and introduced INSTR_TIME_SET_CURRENT_FAST() which > uses RDTSC. > > I haven't gotten to the following: > > - Looking through all calls to INSTR_TIME_SET_CURRENT() and check if they > should be replaced by INSTR_TIME_SET_CURRENT_FAST(). - Reviewing Andres > commits. Potentially improving on pg_test_timing's output. - Looking at > enabling RDTSC on more platforms. Is there a minimum set of platforms we > would like support for? Windows should be easy. That would also allow to > unify the code a little more. - Add more documentation and do more testing > around the calls to CPUID. - Profiling and optimizing the code. A quick test > showed about 10% improvement over master with TIMING ON vs TIMING OFF, when > using the test-case from Andres' e-mail that started this thread. > > I hope I'll find time to work on these points during the next days. This fails to build on several platforms: https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest%2F42%2F3751 Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: