Re: patch - per-tablespace random_page_cost/seq_page_cost

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: patch - per-tablespace random_page_cost/seq_page_cost
Дата
Msg-id 003601ca709f$40f1cd60$c2d56820$@com
обсуждение исходный текст
Ответ на Re: patch - per-tablespace random_page_cost/seq_page_cost  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: patch - per-tablespace random_page_cost/seq_page_cost
Список pgsql-hackers
Robert Haas Wrote:
> Hmm.  I'm not able to reliably detect a performance difference between
> unpatched CVS HEAD (er... git master branch) and same with spcoptions-
> v2.patch applied.  I figured that if there were going to be an impact,
> it would be most likely to manifest itself in a query that touches lots
> and lots of tables but does very little actual work.  So I used the
> attached script to create 200 empty tables, 100 in the default
> tablespace and 100 in tablespace "dork" (also known as, why I am
> working on this at 11 PM on Thanksgiving).  Then I did:
> 
> SELECT * FROM a1, a2, a3, ..., a100;

(I've not read the patch, but I've just read the thread)
If you're just benchmarking the planner times to see if the extra lookups
are affecting the planning times, would it not be better to benchmark
EXPLAIN SELECT * FROM a1, a2, a3, ..., a100; ?
Otherwise any small changes might be drowned out in the execution time.
Scanning 100 relations even if they are empty could account for quite a bit
of that time, right?

David



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: plperl and inline functions -- first draft
Следующее
От: Tom Lane
Дата:
Сообщение: Re: plperl and inline functions -- first draft