Re: patch - per-tablespace random_page_cost/seq_page_cost - Mailing list pgsql-hackers

From David Rowley
Subject Re: patch - per-tablespace random_page_cost/seq_page_cost
Date
Msg-id 003601ca709f$40f1cd60$c2d56820$@com
Whole thread Raw
In response to Re: patch - per-tablespace random_page_cost/seq_page_cost  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: patch - per-tablespace random_page_cost/seq_page_cost
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: plperl and inline functions -- first draft
Next
From: Tom Lane
Date:
Subject: Re: plperl and inline functions -- first draft