On Wed, Jun 17, 2009 at 3:44 AM, Kevin Grittner wrote:
> Andrew Dunstan wrote:
>
> > If a table is created or truncated in the same transaction that does
> > the load, and archiving is not on, the COPY is not WALed.
>
> Slightly off topic, but possibly relevant to the overall process:
> those ar
Merlin Moncure wrote:
On Tue, Jun 16, 2009 at 12:47 PM, Stefan
Kaltenbrunner wrote:
Hi!
I have been doing some bulk loading testing recently - mostly with a focus
on answering why we are "only" getting a (max of) cores/2(up to around 8
cores even less with more) speedup using parallel restore.
Andrew Dunstan wrote:
> If a table is created or truncated in the same transaction that does
> the load, and archiving is not on, the COPY is not WALed.
Slightly off topic, but possibly relevant to the overall process:
those are the same conditions under which I would love to see the
rows inse
Merlin Moncure wrote:
On Tue, Jun 16, 2009 at 12:47 PM, Stefan
Kaltenbrunner wrote:
Hi!
I have been doing some bulk loading testing recently - mostly with a focus
on answering why we are "only" getting a (max of) cores/2(up to around 8
cores even less with more) speedup using parallel rest
On Tue, Jun 16, 2009 at 12:47 PM, Stefan
Kaltenbrunner wrote:
> Hi!
>
> I have been doing some bulk loading testing recently - mostly with a focus
> on answering why we are "only" getting a (max of) cores/2(up to around 8
> cores even less with more) speedup using parallel restore.
> What I found i
Hi!
I have been doing some bulk loading testing recently - mostly with a
focus on answering why we are "only" getting a (max of) cores/2(up to
around 8 cores even less with more) speedup using parallel restore.
What I found is that on some fast IO-subsystem we are CPU bottlenecked
on concurren
