From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | 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-19 01:42:00 |
Message-ID: | 200701181842.00696.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Troy | 2007-01-19 01:48:17 | Re: Spam from EnterpriseDB? |
Previous Message | Klint Gore | 2007-01-19 01:33:15 | Re: Spam from EnterpriseDB? |