Re: Index bloat of 4x

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>
Cc: pgsql-general(at)postgresql(dot)org, Bill Moran <wmoran(at)collaborativefusion(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: Index bloat of 4x
Date: 2007-01-31 04:14:52
Message-ID: 200701310414.l0V4EqF18895@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


I found this thread quite depressing because I had forgotten the VACUUM
FULL only reclaims totally empty pages. I have applied the following
documentation patch to recommend periodic REINDEX, and backpatched to
8.2.X docs. I also added some TODO items so hopefully at least we will
keep track of this limitation.

---------------------------------------------------------------------------

Ed L. wrote:
> On Thursday January 18 2007 6:07 am, Bill Moran wrote:
> > Right. It doesn't _look_ that way from the graph, but that's
> > because I only graph total DB size. I expect if I graphed
> > data and index size separately, it would be evident.
>
> pg_total_relation_size() might give you what you want there.
>
> > At this point, I'm going to assume that my question of, "Is
> > this 4x bloat strange enough to warrant further investigation"
> > is "no". It seems like this amount of bloat isn't terribly
> > unusual, and that the people working on improving this sort of
> > thing already have enough examples of it.
>
> I afraid I don't see how any of the answers I saw discussed fit a
> 24x7 operation. Reindex, drop index, vacuum full, ... they all
> block production queries of one sort or another for significant
> periods of time (minutes) on large (multi/tens of GB) tables,
> and thus are infeasible for true 24x7 operations. What it seems
> we really need is something to remove the bloat without blocking
> production DML queries, while under significant query load, with
> very large tables. This bloat issue is by far our biggest
> headache on the DB side.
>
> Ed
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Attachment Content-Type Size
/rtmp/diff text/x-diff 2.1 KB

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2007-01-31 04:15:20 Re: Any Plans for cross database queries on the same server?
Previous Message Tom Lane 2007-01-31 04:08:58 Re: VACUUM and open transactions