Thread: FW:
No, it is one transaction per insert. -----Original Message----- From: Scott Marlowe [mailto:smarlowe@g2switchworks.com] Sent: Tuesday, May 08, 2007 5:38 PM To: Orhan Aglagul Subject: RE: [PERFORM] On Tue, 2007-05-08 at 19:36, Orhan Aglagul wrote: > But 10,000 records in 65 sec comes to ~153 records per second. On a dual > 3.06 Xeon.... > What range is acceptable? If you're doing that in one big transaction, that's horrible. Because it shouldn't be waiting for each insert to fsync, but the whole transaction.
On Tue, 8 May 2007, Orhan Aglagul wrote: > No, it is one transaction per insert. > > -----Original Message----- > From: Scott Marlowe [mailto:smarlowe@g2switchworks.com] > Sent: Tuesday, May 08, 2007 5:38 PM > To: Orhan Aglagul > Subject: RE: [PERFORM] > > On Tue, 2007-05-08 at 19:36, Orhan Aglagul wrote: >> But 10,000 records in 65 sec comes to ~153 records per second. On a > dual >> 3.06 Xeon.... >> What range is acceptable? > > If you're doing that in one big transaction, that's horrible. Because > it shouldn't be waiting for each insert to fsync, but the whole > transaction. with a standard 7200 rpm drive ~150 transactions/sec sounds about right to really speed things up you want to get a disk controller with a battery backed cache so that the writes don't need to hit the disk to be safe. that should get your speeds up to (and possibly above) what you got by turning fsync off. David Lang
<david@lang.hm> writes: > with a standard 7200 rpm drive ~150 transactions/sec sounds about right > > to really speed things up you want to get a disk controller with a battery > backed cache so that the writes don't need to hit the disk to be safe. Note that this is only if you're counting transactions/sec in a single session. You can get much more if you have many sessions since they can all commit together in a single disk i/o. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com