From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Review: Revise parallel pg_restore's scheduling heuristic |
Date: | 2009-07-30 17:24:15 |
Message-ID: | 15048.1248974655@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> The timings vary by up to 2.5% between runs, so that's the noise
> level. Five runs of each (alternating between the two) last night
> give an average performance of 1.89% faster for the patched version.
> Combining that with yesterday's results starts to give me pretty good
> confidence that the patch is beneficial for this database with this
> configuration. I haven't found any database or configuration where it
> hurts. (For most tests, adding up the results gave a net difference
> measured in thousandths of a percent.)
> Is that good enough, or is it still worth the effort of constructing
> the artificial case where it might *really* shine? Or should I keep
> running with the "real" database a few more nights to get a big enough
> sample to further increase the confidence level with this test?
I think we've pretty much established that it doesn't make things
*worse*, so I'm sort of inclined to go ahead and apply it. The
theoretical advantage of eliminating O(N^2) search behavior seems
like reason enough, even if it takes a ridiculous number of tables
for that to become significant.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-07-30 17:29:16 | Re: Review: Revise parallel pg_restore's scheduling heuristic |
Previous Message | Pavel Stehule | 2009-07-30 17:18:27 | Re: WIP: to_char, support for EEEE format |