Skip site navigation (1) Skip section navigation (2)

Re: Trivial patch to double vacuum speed on tables with no indexes

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: Trivial patch to double vacuum speed on tables with no indexes
Date: 2006-08-27 17:00:15
Message-ID: 873bbim7vk.fsf@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> stark <stark(at)enterprisedb(dot)com> 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

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2006-08-27 17:07:39
Subject: Re: integration of pgcluster into postgresql
Previous:From: Tom LaneDate: 2006-08-27 16:47:12
Subject: Re: integration of pgcluster into postgresql

pgsql-patches by date

Next:From: Tom LaneDate: 2006-08-27 17:12:31
Subject: Re: [HACKERS] Trivial patch to double vacuum speed on tables with no indexes
Previous:From: Tom LaneDate: 2006-08-27 16:33:54
Subject: Re: Trivial patch to double vacuum speed on tables with no indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group