Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZcYBh-0000Qh-E7 for pgsql-performance@arkaria.postgresql.org; Thu, 17 Sep 2015 12:21:17 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZcYBg-00086P-Qp for pgsql-performance@arkaria.postgresql.org; Thu, 17 Sep 2015 12:21:16 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZcYA2-0005bJ-9T for pgsql-performance@postgresql.org; Thu, 17 Sep 2015 12:19:34 +0000 Received: from mail.tzv.fal.de ([192.108.34.20]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZcY9y-0007zv-Mk for pgsql-performance@postgresql.org; Thu, 17 Sep 2015 12:19:33 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.tzv.fal.de (Postfix) with ESMTP id 42AB010692785; Thu, 17 Sep 2015 14:19:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.tzv.fal.de Received: from mail.tzv.fal.de ([127.0.0.1]) by localhost (mail.tzv.fal.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2becBJHKDRk; Thu, 17 Sep 2015 14:19:26 +0200 (CEST) Received: from eno (unknown [46.21.0.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.tzv.fal.de (Postfix) with ESMTPSA id 388E010001FEA; Thu, 17 Sep 2015 14:19:26 +0200 (CEST) Message-ID: <1442492365.4959.18.camel@fli.bund.de> Subject: Re: degrading inser performance From: Eildert Groeneveld Reply-To: eildert.groeneveld@fli.bund.de To: Ladislav Lenart , postgres performance list Date: Thu, 17 Sep 2015 14:19:25 +0200 In-Reply-To: <55FAAE0B.9020506@volny.cz> References: <1442489550.4959.12.camel@fli.bund.de> <55FAAE0B.9020506@volny.cz> Organization: FLI Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5-1ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On Do, 2015-09-17 at 14:11 +0200, Ladislav Lenart wrote: > On 17.9.2015 13:32, Eildert Groeneveld wrote: > > Dear list > > > > I am experiencing a rather severe degradation of insert performance > > starting from an empty database: > > > > > > 120.000 mio SNPs imported in 28.9 sec - 4.16 mio/sec > > 120.000 mio SNPs imported in 40.9 sec - 2.93 mio/sec > > 120.000 mio SNPs imported in 49.7 sec - 2.41 mio/sec > > 120.000 mio SNPs imported in 58.8 sec - 2.04 mio/sec > > 120.000 mio SNPs imported in 68.9 sec - 1.74 mio/sec > > 120.000 mio SNPs imported in 77.0 sec - 1.56 mio/sec > > 120.000 mio SNPs imported in 85.1 sec - 1.41 mio/sec > > 120.000 mio SNPs imported in 94.0 sec - 1.28 mio/sec > > 120.000 mio SNPs imported in 103.4 sec - 1.16 mio/sec > > 120.000 mio SNPs imported in 108.9 sec - 1.10 mio/sec > > 120.000 mio SNPs imported in 117.2 sec - 1.02 mio/sec > > 120.000 mio SNPs imported in 122.1 sec - 0.98 mio/sec > > 120.000 mio SNPs imported in 132.6 sec - 0.90 mio/sec > > 120.000 mio SNPs imported in 142.0 sec - 0.85 mio/sec > > 120.000 mio SNPs imported in 147.3 sec - 0.81 mio/sec > > 120.000 mio SNPs imported in 154.4 sec - 0.78 mio/sec > > 120.000 mio SNPs imported in 163.9 sec - 0.73 mio/sec > > 120.000 mio SNPs imported in 170.1 sec - 0.71 mio/sec > > 120.000 mio SNPs imported in 179.1 sec - 0.67 mio/sec > > 120.000 mio SNPs imported in 186.1 sec - 0.64 mio/sec > > > > each line represents the insertion of 20000 records in two tables > > which is > > not really a whole lot. Also, these 20000 get inserted in one > > program run. > > The following lines are then again each the execution of that > > program. > > The insert are a text string in one table and a bit varying of > > length packed > > 24000 bits, also no big deal. > > > > As can be seen the degradation is severe going from 29 sec up to > > 186 sec > > for the same amount of data inserted. > > > > I have dropped the indices and primary keys, but that did not > > change the > > picture. Made commits every 100 records: also no effect. > > I have also played around with postgresql.conf but also this had no > > real > > effect (which is actually not surprising considering the small size > > of the > > database). > > > > At this stage the who database has a size of around 1GB. > > > > I am using pg 9.4 > > > > any idea of what might be going on? > > > Hello. > > Just a couple of questions... > > You talk about two tables; have you also dropped FKs (you only > mention indices > and PK)? yes, they were all gone > > What SQL do you use for inserting the data: I go through ecpg > * one INSERT per row with autocommit yes > * one INSERT per row inside BEGIN...COMMIT also this, same result as above > * one INSERT per bulk (20 000 rows) > * one COPY per bulk (20 000 rows) copy does not fit so well, as it is not only initial populating. > Is the loading of data the only activity on the server? yes, it is. I have this "feature" on every machine > See also: > http://www.postgresql.org/docs/9.4/static/populate.html Thanks, yes, I have been through this. millions of records seem to be the staple diet of PG, here the degradation starts already with the second 20000 record batch. > greetings Eildert > HTH, > > Ladislav Lenart > > -- Eildert Groeneveld =================================================== Institute of Farm Animal Genetics (FLI) Mariensee 31535 Neustadt Germany Tel : (+49)(0)5034 871155 Fax : (+49)(0)5034 871143 e-mail: eildert.groeneveld@fli.bund.de web: http://vce.tzv.fal.de ================================================== -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance