On Thu, Jul 30, 2009 at 12:29:34PM -0500, Kevin Grittner wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > 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.
>
> Agreed, although I'm having some concerns about whether this should
> proceed based exclusively on my benchmarks. On a thread on the
> performance list, people are talking about restores which go several
> times faster with parallel restore (compared to a single job). On my
> hardware, I haven't even gotten it to run twice as fast. This means
> that parallel restore is not a good fit for servers like we have, at
> least with databases like we have, which means it's probably a poor
> environment to get benchmarks for this patch. :-(
>
> Can we get someone who has benchmarks showing parallel restore to be
> eight times the speed of a single job to benchmark with this patch,
> just for confirmation?
I have a couple "spare" 32GB 4 core and 64GB 8 core servers with 15 scsi/sas
drives and dumps of production dbs in the 100GB to 500 GB range. These have
several hundred tables most with an index or few and an fkey or too many.
It will take a couple days to run a variety of tests I suppose, and I will
be away starting mid next week, but maybe I could get some done before I go.
Will the patch apply to a vanilla 8.4.0?
-dg
--
David Gould daveg@sonic.net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.