From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Erik Jones <erik(at)myemma(dot)com>, Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: why postgresql over other RDBMS |
Date: | 2007-05-26 18:42:44 |
Message-ID: | 46587FA4.6030202@kaltenbrunner.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
>> Tom Lane wrote:
>>> A more interesting question is what sort of hardware you need for that
>>> actually to be a win, though. Loading a few tables in parallel sounds
>>> like an ideal recipe for oversaturating your disk bandwidth...
>
>> you don't actually need that much of disk bandwidth both COPY and CREATE
>> INDEX are CPU bottlenecked on modern boxes and reasonable disk
>> subsystems - spreading their work over multiple cores/processes can give
>> big benefits.
>
> Hmm ... I wonder if that's true for COPY BINARY ...
not sure on that - I was simply trying to say that even a simple
parallel dump & restore capability could result in a serious improvement
for people running large databases(especially considering that one can
now buy 1U boxes with 8+ cores or 2U boxes that can hold 14disks+) ;-)
Stefan
From | Date | Subject | |
---|---|---|---|
Next Message | PFC | 2007-05-26 19:18:16 | Re: why postgresql over other RDBMS |
Previous Message | Francisco Reyes | 2007-05-26 18:40:23 | Re: backup strategies |