Hi Richard,
>
> >>> No, as said above transactions are made of 10 inserts...
> >> Hmm - I read that as just meaning "inserted 10 rows". You might find
> >> that smaller batches provide peak performance.
>
> > Ahh ok ;-) sorry for my bad english... (yeah, i have been testing
> > several tra
Hi Andreas,
Thanks for the info about COPY !!
On Mar 6, 1:23 pm, [EMAIL PROTECTED] (Andreas Kostyrka) wrote:
> * Richard Huxton <[EMAIL PROTECTED]> [070306 12:22]:> >>2. You can do a COPY
> from libpq - is it really not possible?
>
> > >Not really but i have been testing it and inserts are flyin
urn as
> soon as the data gets to the disk cache, not the physical disk. SCSI disks
> are almost always more correct, and wait until the data gets to the physical
> disk before they return from an fsync call.
>
> I hope this helps.
>
> Regards,
>
> Ben"hatman"
Hi all,
Do someone already had some problem with performances using a pentium
D (64 bits) and postgres 8.2.3 on a redhat enterprise update 2 ?
I did the install from sources and nothing change... I have a RAID 0
for data and 3Gb of RAM and my inserts rate is quite low, 8333 inserts/
sec (lower tha
Dear all,
After many tests and doc reading, i finally try to get help from
you...
Here is my problem. With some heavy insert into a simple BD (one
table, no indexes) i can't get better perf than 8000 inserts/sec. I'm
testing it using a simple C software which use libpq and which use:
- Insert pre
