X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id 45AB3D1B539 for ; Mon, 18 Aug 2003 16:00:46 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024) with ESMTP id 28626-03 for ; Mon, 18 Aug 2003 13:00:35 -0300 (ADT) Received: from smtp.pspl.co.in (unknown [202.54.11.65]) by svr1.postgresql.org (Postfix) with ESMTP id E3556D1B56B for ; Mon, 18 Aug 2003 13:00:33 -0300 (ADT) Received: (from root@localhost) by smtp.pspl.co.in (8.12.9/8.12.9) id h7IG4XZo028354 for ; Mon, 18 Aug 2003 21:34:33 +0530 Received: from daithan (daithan.intranet.pspl.co.in [192.168.7.161]) (authenticated bits=0) by persistent.co.in (8.12.9/8.12.9) with ESMTP id h7IG4W3g028341 for ; Mon, 18 Aug 2003 21:34:33 +0530 From: "Shridhar Daithankar" To: pgsql-performance@postgresql.org Date: Mon, 18 Aug 2003 21:32:27 +0530 MIME-Version: 1.0 Subject: Re: Insert performance Reply-To: shridhar_daithankar@persistent.co.in Message-ID: <3F4145EB.20645.B5452D9@localhost> In-reply-to: <1061221963.2620.4.camel@fuji.krosing.net> References: <3F40BDC4.1605.9407ADF@localhost> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200308/284 X-Sequence-Number: 3100 On 18 Aug 2003 at 18:52, Hannu Krosing wrote: > My own experimentation also got numbers in 9k/sec range (on a quad > 1.3GHz Xeons, 2GM mem, 50MB/sec raid) when doing 10-20 parallel runs of > ~1000 inserts/transaction. > > Performance dropped to ~300/sec (at about 60M rows) when I added an > index (primary key) - as I did random inserts, the hit rates for index > pages were probably low. I was loading a geographic data couple of months back.. It was 3GB data when loaded in postgresql. I tried loading data first and creating index later. It ran out of available 9GB space. So I created index on an empty table and started loading it. It was slow but at least finished after 3 hours... Co-incidentally oracle had same problems as well. So creating index beforehand remains only option at times, it seems. Tom remarked that it shouldn't have made difference but apparently it does.. You mentioned parallel runs and still getting 9K/sec. Was that overall 9K or per connection? If it is former, probably WAL is hit too hard. You could do some additional testing by having WALit's own disk. I was plannning to do the multiple writers test. But since objective was to find out why postgresql was so slow and it tunred out to be slowaris in first place, didn't have any enthu. left. I recommended my colleague to move to linux. But apparently this product is a part of suit which runs on some HUGE solaris machines. So if it has to run postgresql, it has to run sunos. I hope they are faster with SCSI.. Bye Shridhar -- On my planet, to rest is to rest -- to cease using energy. To me, itis quite illogical to run up and down on green grass, using energy,instead of saving it. -- Spock, "Shore Leave", stardate 3025.2