scott.marlowe wrote:
> On Fri, 3 Oct 2003, scott.marlowe wrote:
>
> > On Fri, 3 Oct 2003, Tom Lane wrote:
> > >
> > > It'd be interesting to think about whether a write-caching IDE drive
> > > could safely be used for data storage, if WAL is elsewhere.
> >
> > Well, I just so happen to have a ma
On Fri, 3 Oct 2003, scott.marlowe wrote:
> On Fri, 3 Oct 2003, Tom Lane wrote:
> >
> > It'd be interesting to think about whether a write-caching IDE drive
> > could safely be used for data storage, if WAL is elsewhere.
>
> Well, I just so happen to have a machine with two drives in it. I'll ge
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> Yes, you are. Basically, with fsync on, things have to happen in order.
> I.e.
> write to WAL what you're gonna do. WAIT for confirmation on write
> write the tuples out. wait for confirmation
> checkpoint the WAL. wait for confirmation
Not really.
> "sm" == scott marlowe writes:
sm> also, turning off fsync during the load helps a lot. Be sure to turn it
sm> back on when you're done of course.
Only if you don't have a battery-backed cache on your RAID. If you
do, it won't likely make a big difference. For me it was about 2
seconds
On Fri, 3 Oct 2003, Alvaro Herrera wrote:
> On Fri, Oct 03, 2003 at 01:06:26PM -0600, scott.marlowe wrote:
>
> > also, turning off fsync during the load helps a lot. Be sure to turn it
> > back on when you're done of course.
>
> I'm not sure I understand why this is so. If I turn fsync off, i
On Fri, 3 Oct 2003, Vivek Khera wrote:
> > "sm" == scott marlowe writes:
>
> sm> also, turning off fsync during the load helps a lot. Be sure to turn it
> sm> back on when you're done of course.
>
> Only if you don't have a battery-backed cache on your RAID. If you
> do, it won't likely
Vivek Khera wrote:
SD> footprint. I dropped the table and recreated it. Also created index
SD> before loading data. The loading was slow with this approach but it
SD> finished in 3 hours. And I had an updated index as well. Just had to
SD> run vacuum over it.
I cannot believe that this was faster t
> "SD" == Shridhar Daithankar <[EMAIL PROTECTED]> writes:
SD> You can try creating index/triggers first and load the data. At the
SD> end it will take a while before you get a usable database with either
SD> approach but see what works faster for you.
The triggers and FK's don't do much at th
