Re: Review: Revise parallel pg_restore's scheduling heuristic

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "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 14:43:43
Message-ID: 4A716B4F02000025000290AD@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:

> with the default settings, the patched version ran an additional 1%
> faster than the unpatched; although I don't have enough samples to
> have a high degree of confidence it wasn't noise. I'll run another
> slew of tests tonight with the existing dump file to confirm to
> debunk that result

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?

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brendan Jurd 2009-07-30 14:54:23 Re: WIP: to_char, support for EEEE format
Previous Message Brendan Jurd 2009-07-30 14:35:49 Re: WIP: to_char, support for EEEE format