On Fri, 2 Dec 2005, Luke Lonergan wrote:
> Micahel,
>
> On 12/2/05 1:46 PM, "Michael Stone" <mstone+postgres@mathom.us> wrote:
>
>> Not necessarily; you may be betting that it's more *efficient* to do the
>> parsing on a bunch of lightly loaded clients than your server. Even if
>> you're using the same code this may be a big win.
>
> If it were possible in light of the issues on client parse / convert, then
> we should analyze whether it's a performance win.
>
> In the restore case, where we've got a dedicated server with a dedicated
> client machine, I don't see why there would be a speed benefit from running
> the same parse / convert code on the client versus running it on the server.
> Imagine a pipeline where there is a bottleneck, moving the bottleneck to a
> different machine doesn't make it less of a bottleneck.
your database server needs to use it's CPU for
other things besides the parseing. you could buy a bigger machine, but
it's useally far cheaper to buy two dual-proc machines then it is one
quad proc machine (and if you load is such that you already have a
8-proc machine as the database, swallow hard when you ask for the price
of a 16 proc machine), and in addition there is a substantial efficiancy
loss in multi-proc machines (some software, some hardware) that may give
you more available work cycles on the multiple small machines.
if you can remove almost all the parsing load (CPU cycles, memory
footprint, and cache thrashing effects) then that box can do the rest of
it's stuff more efficiantly. meanwhile the client can use what would
otherwise be idle CPU to do the parseing.
if you only have a 1-1 relationship it's a good question as to if it's a
win (it depends on how much other stuff each box is having to do to
support this), but if you allow for multiple clients it easily becomes a
win.
David Lang
