Re: Planning time in explain/explain analyze

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Planning time in explain/explain analyze
Дата
Msg-id 17920.1389302050@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Planning time in explain/explain analyze  (Greg Stark <stark@mit.edu>)
Ответы Re: Planning time in explain/explain analyze  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> However I don't see the issue here. Two gettimeofday calls per query
> plan is not really going to hurt even on systems where it's slow.

I tend to agree with this, especially if the calls only occur when the
user asks for the information (ie, does an EXPLAIN rather than just
executing the query).

> The only way two gettimeofday calls per query plan becomes an issue is
> if you're executing non-cached queries repeatedly on data that's
> entirely in ram. That means the query processing is entirely cpu-bound
> and adding two syscalls could actually be noticeable. The mitigation
> strategy would be to prepare and cache the query handle to execute it
> again.

This point weighs against the proposal that we time the work to fetch
a previously-prepared query plan; if we do that then the "mitigation
strategy" doesn't mitigate anything.

In short then, I think we should just add this to EXPLAIN and be done.
-1 for sticking the info into PlannedStmt or anything like that.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Steeve Lennmark
Дата:
Сообщение: Re: [PATCH] Relocation of tablespaces in pg_basebackup
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Turning off HOT/Cleanup sometimes