Re: [HACKERS] Autovacuum Improvements - Mailing list pgsql-general

From Heikki Linnakangas
Subject Re: [HACKERS] Autovacuum Improvements
Date
Msg-id 45B4DEA4.6070503@enterprisedb.com
Whole thread Raw
In response to Re: [HACKERS] Autovacuum Improvements  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [HACKERS] Autovacuum Improvements  (Bruce Momjian <bruce@momjian.us>)
List pgsql-general
Bruce Momjian wrote:
> Heikki Linnakangas wrote:
>> Russell Smith wrote:
>>> 2. Index cleanup is the most expensive part of vacuum.  So doing a
>>> partial vacuum actually means more I/O as you have to do index cleanup
>>> more often.
>> I don't think that's usually the case. Index(es) are typically only a
>> fraction of the size of the table, and since 8.2 we do index vacuums in
>> a single scan in physical order. In fact, in many applications the index
>> is be mostly cached and the index scan doesn't generate any I/O at all.
>
> Are _all_ the indexes cached?  I would doubt that.

Well, depends on your schema, of course. In many applications, yes.

>  Also, for typical
> table, what percentage is the size of all indexes combined?

Well, there's no such thing as a typical table. As an anecdote here's
the ratios (total size of all indexes of a table)/(size of corresponding
heap) for the bigger tables for a DBT-2 run I have at hand:

Stock:        1190470/68550 = 6%
Order_line:    950103/274372 = 29%
Customer:    629011 /(5711+20567) = 8%

In any case, for the statement "Index cleanup is the most expensive part
of vacuum" to be true, you're indexes would have to take up 2x as much
space as the heap, since the heap is scanned twice. I'm sure there's
databases like that out there, but I don't think it's the common case.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

pgsql-general by date:

Previous
From: "Jan Muszynski"
Date:
Subject: Re: security question
Next
From: Tom Lane
Date:
Subject: Re: CAST function for user defined type