Re: patch - per-tablespace random_page_cost/seq_page_cost

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