X-Original-To: pgsql-patches-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id A3D519FC626; Sun, 27 Aug 2006 14:00:19 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 57100-10; Sun, 27 Aug 2006 17:00:16 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from localhost.localdomain (host86-130-26-100.range86-130.btcentralplus.com [86.130.26.100]) by postgresql.org (Postfix) with ESMTP id 35B039FC63C; Sun, 27 Aug 2006 14:00:15 -0300 (ADT) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by localhost.localdomain with esmtp (Exim 4.62) (envelope-from ) id 1GHNzb-0000Bj-75; Sun, 27 Aug 2006 18:00:15 +0100 To: Tom Lane Cc: pgsql-hackers@postgresql.org, pgsql-patches@postgresql.org Subject: Re: Trivial patch to double vacuum speed on tables with no indexes In-Reply-To: <1297.1156696434@sss.pgh.pa.us> (Tom Lane's message of "Sun, 27 Aug 2006 12:33:54 -0400") X-Draft-From: ("nnimap+webmail.enterprisedb.com:Inbox" 790) References: <877j0umfqx.fsf@enterprisedb.com> <1297.1156696434@sss.pgh.pa.us> From: Gregory Stark Organization: EnterpriseDB Date: Sun, 27 Aug 2006 18:00:15 +0100 Message-ID: <873bbim7vk.fsf@enterprisedb.com> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=4.127 tagged_above=0 required=5 tests=FORGED_RCVD_HELO, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: **** X-Archive-Number: 200608/387 X-Sequence-Number: 20903 Tom Lane writes: > stark writes: >> There isn't really any need for the second pass in lazy vacuum if the table >> has no indexes. > > How often does that case come up in the real world, for tables that are > large enough that you'd care about vacuum performance? Admittedly it's not the most common scenario. But it does come up. ETL applications for example that load data, then perform some manipulation of the data before loading the data. If they have many updates to do they'll probably have to do vacuums between some of them. Arguably if you don't have any indexes on a large table it's quite likely to be *because* you're planning on doing some big updates such that it'll be faster to simply rebuild the indexes when you're done anyways. I would have had the same objection if it resulted in substantially more complex code but it was so simple that it doesn't seem like a concern. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com