Re: Tuning planner cost estimates

От: Tom Lane
Тема: Re: Tuning planner cost estimates
Дата: ,
Msg-id: 4415.1116630411@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: Tuning planner cost estimates  ("Jim C. Nasby")
Список: pgsql-performance

Скрыть дерево обсуждения

Tuning planner cost estimates  ("Jim C. Nasby", )
 Re: Tuning planner cost estimates  (Josh Berkus, )
  Re: Tuning planner cost estimates  (Tom Lane, )
   Re: Tuning planner cost estimates  (Josh Berkus, )
  Re: Tuning planner cost estimates  ("Jim C. Nasby", )
   Re: Tuning planner cost estimates  (Tom Lane, )
    Re: Tuning planner cost estimates  ("Jim C. Nasby", )
     Re: Tuning planner cost estimates  (Tom Lane, )
   Re: Tuning planner cost estimates  (Josh Berkus, )
    Re: Tuning planner cost estimates  ("Jim C. Nasby", )
    Re: Tuning planner cost estimates  (Simon Riggs, )

"Jim C. Nasby" <> writes:
> Does this sound like a reasonable approach? Also, how important do
> people think it is to use explain analyze output instead of just doing
> SELECT count(*) FROM (query you actually want to test)? (The select
> count(*) wrapper is just a means to throw away the results since we
> don't really want to worry about data transfer times, etc). The testing
> I've done (http://stats.distributed.net/~decibel/base.log) shows explain
> analyze to be almost 5x slower than select count(*), so it seems a big
> gain if we can avoid that.

I'd go with the select count(*) --- I can't imagine that we will be
trying to model the behavior of anything so complex that we really need
explain analyze output.  (On the other hand, recording explain output is
a good idea to make sure you are testing what you think you are testing.)

Actually, it might be worth using "select count(null)", which should
avoid the calls to int8inc.  I think this doesn't matter so much in CVS
tip, but certainly in existing releases the palloc overhead involved is
noticeable.

BTW, 5x is an awful lot; I've not noticed overheads more than about 2x.

            regards, tom lane


В списке pgsql-performance по дате сообщения:

От: Tom Lane
Дата:
Сообщение: Re: Tuning planner cost estimates
От: Alex Stapleton
Дата:
Сообщение: Re: Optimizing for writes. Data integrity not critical