From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowley(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: patch - per-tablespace random_page_cost/seq_page_cost |
Date: | 2009-12-18 01:57:38 |
Message-ID: | 603c8f070912171757k2ca25f69je8899acac478d888@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 3, 2009 at 11:00 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Nov 28, 2009 at 9:54 PM, David Rowley <dgrowley(at)gmail(dot)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.
I did some fairly careful benchmarking of EXPLAIN SELECT * FROM a1,
a2, a3, ..., a100. I explained this query 100 times via DBD::Pg and
used time to measure how long the script took to run. I ran the
script three times. And the result is... the unpatched version came
out 1.7% SLOWER than the patched version. This seems difficult to
take seriously, since it can't possibly be faster to do a syscache
lookup and parse an array than it is to fetch a constant from a known
memory address, but that's what I got. At any rate, it seems pretty
clear that it's not hurting much.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-12-18 02:15:50 | Re: patch - per-tablespace random_page_cost/seq_page_cost |
Previous Message | Takahiro Itagaki | 2009-12-18 00:27:51 | Re: Largeobject Access Controls (r2460) |