X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 9E11AD1B55D for ; Mon, 17 Nov 2003 06:18:17 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 04435-02 for ; Mon, 17 Nov 2003 02:17:47 -0400 (AST) Received: from smtp.istop.com (dci.doncaster.on.ca [66.11.168.194]) by svr1.postgresql.org (Postfix) with ESMTP id 9EDF5D1BA8B for ; Mon, 17 Nov 2003 02:17:46 -0400 (AST) Received: from stark.dyndns.tv (gsstark.mtl.istop.com [66.11.160.162]) by smtp.istop.com (Postfix) with ESMTP id D1244369CD; Mon, 17 Nov 2003 01:17:45 -0500 (EST) Received: from localhost ([127.0.0.1] helo=stark.dyndns.tv ident=foobar) by stark.dyndns.tv with smtp (Exim 3.36 #1 (Debian)) id 1ALchl-0000pe-00; Mon, 17 Nov 2003 01:17:45 -0500 To: ow Cc: Jan Wieck , pgsql-sql@postgresql.org Subject: Re: Programatically switching database References: <20031116051842.57962.qmail@web21404.mail.yahoo.com> In-Reply-To: <20031116051842.57962.qmail@web21404.mail.yahoo.com> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 17 Nov 2003 01:17:45 -0500 Message-ID: <87brrba586.fsf@stark.dyndns.tv> Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200311/191 X-Sequence-Number: 16006 ow writes: > My concern though ... wouldn't pgSql server collapse when faced with > transaction spawning across 100M+ records? The number of records involved really doesn't faze Postgres at all. However the amount of time spent in the transaction could be an issue if there is other activity in other schemas of the same database. As long as the transaction is running none of the deleted or old updated data in any schema of the database can be cleaned up by vacuum as postgres thinks the big transaction "might" need to see it sometime. So if the rest of the database is still active the tables and indexes being updated may grow larger than normal. If it goes on for a _really_ long time they might need a VACUUM FULL at some point to clean them up. -- greg