On Sat, Nov 28, 2009 at 9:54 PM, David Rowley <dgrow...@gmail.com> wrote: > 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?
Possibly, but even if I can measure a difference doing it that way, it's not clear that it matters. It's fairly certain that there will be a performance degradation if we measure carefully enough, but if that difference is imperceptible in real-world scanerios, then it's not worth worrying about. Still, I probably will test it just to see. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
