Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
| От | Robert Haas |
|---|---|
| Тема | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
| Дата | |
| Msg-id | CA+TgmobAbCwvZMnMPJA9OBzHYbEsGCwCmOHPr0wRVxjkEo7RDQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? (Lukas Fittl <lukas@fittl.com>) |
| Список | pgsql-hackers |
On Wed, Nov 19, 2025 at 11:55 AM Lukas Fittl <lukas@fittl.com> wrote: > Overall, I'm still thinking a GUC might be the way to go, but I don't think anyone else was enthusiastic about that idea:) Reliable feature auto-detection is the best option, but if that's not possible, I think the choices are add a GUC or give up on the project altogether. Using a GUC to deal with platform dependencies is a pretty reasonable concept -- see, e.g. dynamic_shared_memory_type or huge_pages or io_method. If we can't autodetect it reliably and we aren't willing to add a GUC, we're basically saying there's not enough value here to justify adding a configuration parameter. That's often a totally reasonable conclusion -- it can easily happen that the benefits of a platform-specific optimization are too small to make it worth configuring. But I would have thought that in this case the benefits might be quite large. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: