X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 0DD929FA4E0 for ; Wed, 26 Jul 2006 13:02:42 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 99448-01 for ; Wed, 26 Jul 2006 13:02:33 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.aeccom.com (port-83-236-156-26.static.qsc.de [83.236.156.26]) by postgresql.org (Postfix) with ESMTP id 8D72B9FA508 for ; Wed, 26 Jul 2006 13:02:33 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.aeccom.com (Postfix) with ESMTP id 0240F1C65F; Wed, 26 Jul 2006 18:02:31 +0200 (CEST) Received: from mail.aeccom.com ([127.0.0.1]) by localhost (gate6.aeccom.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00444-01-12; Wed, 26 Jul 2006 18:02:29 +0200 (CEST) Received: from [192.168.2.140] (andes.core.aeccom.com [192.168.2.140]) by mail.aeccom.com (Postfix) with ESMTP id CE2181C57E; Wed, 26 Jul 2006 18:02:29 +0200 (CEST) Message-ID: <44C79213.6050308@aeccom.com> Date: Wed, 26 Jul 2006 18:02:27 +0200 From: Sven Geisler Organization: AEC/communications GmbH User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: nuggets72@free.fr CC: pgsql-performance@postgresql.org Subject: Re: loading increase into huge table with 50.000.000 records References: <1153928087.44c78b975f3a7@imp3-g19.free.fr> In-Reply-To: <1153928087.44c78b975f3a7@imp3-g19.free.fr> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at aeccom.com X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.185 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200607/236 X-Sequence-Number: 20096 Hi Larry, Do you run vacuum and analyze frequently? Did you check PowerPostgresql.com for hints about PostgreSQL tuning? You can increase wal_buffers, checkpoint_segments and checkpoint_timeout much higher. Here is a sample which works for me. wal_buffers = 128 checkpoint_segments = 256 checkpoint_timeout = 3600 Cheers Sven. nuggets72@free.fr schrieb: > Hello, > Sorry for my poor english, > > My problem : > > I meet some performance problem during load increase. > > massive update of 50.000.000 records and 2.000.000 insert with a weekly > frequency in a huge table (+50.000.000 records, ten fields, 12 Go on hard disk) > > current performance obtained : 120 records / s > At the beginning, I got a better speed : 1400 records/s > > > CPU : bi xeon 2.40GHz (cache de 512KB) > postgresql version : 8.1.4 > OS : debian Linux sa 2.6.17-mm2 > Hard disk scsi U320 with scsi card U160 on software RAID 1 > Memory : only 1 Go at this time. > > > My database contains less than ten tables. But the main table takes more than 12 > Go on harddisk. This table has got ten text records and two date records. > > I use few connection on this database. > > I try many ideas : > - put severals thousands operations into transaction (with BEGIN and COMMIT) > - modify parameters in postgres.conf like > shared_buffers (several tests with 30000 50000 75000) > fsync = off > checkpoint_segments = 10 (several tests with 20 - 30) > checkpoint_timeout = 1000 (30-1800) > stats_start_collector = off > > unfortunately, I can't use another disk for pg_xlog file. > > > But I did not obtain a convincing result > > > > My program does some resquest quite simple. > It does some > UPDATE table set dat_update=current_date where id=XXXX ; > And if not found > id does some > insert into table > > > My sysadmin tells me write/read on hard disk aren't the pb (see with iostat) > > > Have you got some idea to increase performance for my problem ? > > Thanks. > > Larry. > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster -- /This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you should not copy it, re-transmit it, use it or disclose its contents, but should return it to the sender immediately and delete your copy from your system. Thank you for your cooperation./ Sven Geisler Tel +49.30.5362.1627 Fax .1638 Senior Developer, AEC/communications GmbH Berlin, Germany