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" <decibel@decibel.org>) |
Список | pgsql-performance |
"Jim C. Nasby" <decibel@decibel.org> 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 по дате отправления: