From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, 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:29:16 |
Message-ID: | 603c8f070907301029h343c586fhdab17615d0843acb@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 30, 2009 at 1:24 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "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.
That makes sense to me, but OTOH if Kevin's willing to be more testing
on some artificial cases, particularly the interleaved-index-names
case, I think those results would be interesting too. We already know
that the slowness of dump + restore is a big issue, so any data we can
gather to understand it better (and perhaps eventually design further
improvements) seems like it would be time well spent.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-07-30 17:29:34 | Re: Review: Revise parallel pg_restore's scheduling heuristic |
Previous Message | Tom Lane | 2009-07-30 17:24:15 | Re: Review: Revise parallel pg_restore's scheduling heuristic |