Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id D0788B5DC0A for ; Mon, 19 Sep 2011 22:15:57 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 77076-04 for ; Tue, 20 Sep 2011 01:15:51 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from tamriel.snowman.net (tamriel.snowman.net [72.66.115.51]) by mail.postgresql.org (Postfix) with ESMTP id A6256B5DC02 for ; Mon, 19 Sep 2011 22:15:51 -0300 (ADT) Received: by tamriel.snowman.net (Postfix, from userid 1000) id C45B322211; Mon, 19 Sep 2011 21:15:51 -0400 (EDT) Date: Mon, 19 Sep 2011 21:15:51 -0400 From: Stephen Frost To: Igor Chudov Cc: pgsql-performance@postgresql.org Subject: Re: Postgres INSERT performance and scalability Message-ID: <20110920011551.GQ12765@tamriel.snowman.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W8kijDWvHeraQFS8" Content-Disposition: inline In-Reply-To: X-Editor: Vim http://www.vim.org/ X-Info: http://www.snowman.net X-Operating-System: Linux/2.6.32-5-amd64 (x86_64) X-Uptime: 21:13:38 up 229 days, 9:43, 13 users, load average: 0.13, 0.08, 0.02 User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.404 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RP_MATCHES_RCVD=-0.504 X-Spam-Level: X-Archive-Number: 201109/281 X-Sequence-Number: 45057 --W8kijDWvHeraQFS8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline * Igor Chudov (ichudov@gmail.com) wrote: > Well, my question is, rather, whether the time to do a bulk INSERT of N > records into a large table, would take substantially longer than a bulk > insert of N records into a small table. In other words, does the populating > time grow as the table gets more and more rows? Oh, in that regard, the answer would generally be 'no'. PostgreSQL maintains a table known as the 'free space map', where it keeps track of where there is 'free space' to insert data into a table. As someone else mentioned, if there's a lot of indexes then it's possible that the increased depth in the index due to the larger number of tuples might mean the larger table is slower, but I don't think it'd make a huge difference, to be honest... Are you seeing that behavior? There's nothing like testing it to see exactly what happens, of course.. Thanks, Stephen --W8kijDWvHeraQFS8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk536UcACgkQrzgMPqB3kigm/gCeJbeACAQbIguKsnLoAigbNFLm Ji4AniJHVewgh6u8/QtExl/Gc1VUSakA =IHw8 -----END PGP SIGNATURE----- --W8kijDWvHeraQFS8--