Christophe writes:
> Given this, is there is a recommended way of detecting bloat in
> indices automatically, rather than just looking at them once in a
> while and saying, "Hm, that looks pretty big"?
contrib/pgstattuple works; it's just too expensive to run every
few minutes ...
On May 27, 2009, at 3:25 PM, Greg Smith wrote:
Interesting and an extremely common request. I just added an item
to the Vacuum section of the TODO list while you were listing issues
and potential solutions here: "Provide more information in order to
improve user-side estimates of dead spa
On Wed, 27 May 2009, Tom Lane wrote:
It's an interesting exercise in trying to estimate bloat without
groveling through the whole relation
Interesting and an extremely common request. I just added an item to the
Vacuum section of the TODO list while you were listing issues and
potential sol
Alvaro Herrera writes:
> Tom Lane wrote:
>> It's an interesting exercise in trying to estimate bloat without
>> groveling through the whole relation, but I seriously doubt you could
>> ever get numbers this way that are trustworthy enough to drive
>> maintenance decisions.
> Well, pg_stattuple is
Tom Lane wrote:
> It's an interesting exercise in trying to estimate bloat without
> groveling through the whole relation, but I seriously doubt you could
> ever get numbers this way that are trustworthy enough to drive
> maintenance decisions.
Well, pg_stattuple is way too expensive to be runnin
Alvaro Herrera writes:
> Brad Nicholson wrote:
>> On Wed, 2009-05-27 at 11:15 -0400, Tom Lane wrote:
>>> I wouldn't trust the calculations that view does in the least.
> If "ma" is supposed to be "maxalign", then this code is broken because
> it only reports mingw32 as 8, all others as 4, which i
Brad Nicholson wrote:
> On Wed, 2009-05-27 at 11:15 -0400, Tom Lane wrote:
> > =?iso-8859-1?Q?Alexander_Sch=F6cke?= writes:
> > > I'm using a view
> > > (http://pgsql.tapoueh.org/site/html/news/20080131.bloat.html) to
> > > display the bloat (unused disk space) of the tables in a PostgreSQL
> > >
On Wed, 2009-05-27 at 11:15 -0400, Tom Lane wrote:
> =?iso-8859-1?Q?Alexander_Sch=F6cke?= writes:
> > I'm using a view
> > (http://pgsql.tapoueh.org/site/html/news/20080131.bloat.html) to
> > display the bloat (unused disk space) of the tables in a PostgreSQL
> > database.
>
> I wouldn't trust th
>What is the output of VACUUM VERBOSE foobar_log?
INFO: vacuuming "public.foobar_log"
INFO: index "bar_index" now contains 23832007 row versions in 118151 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.02s/0.00u sec elapsed 64.1
=?iso-8859-1?Q?Alexander_Sch=F6cke?= writes:
> I'm using a view
> (http://pgsql.tapoueh.org/site/html/news/20080131.bloat.html) to
> display the bloat (unused disk space) of the tables in a PostgreSQL
> database.
I wouldn't trust the calculations that view does in the least.
You might look at con
In response to Alexander Schöcke :
> Hello everybody.
>
> I'm using a view
> (http://pgsql.tapoueh.org/site/html/news/20080131.bloat.html) to display the
> bloat (unused disk space) of the tables in a PostgreSQL database. Using this
> data I want to implement a database maintenance script auto
On Wed, May 27, 2009 at 3:54 PM, Alexander Schöcke
wrote:
> Hello everybody.
>
> I'm using a view
> (http://pgsql.tapoueh.org/site/html/news/20080131.bloat.html) to display the
> bloat (unused disk space) of the tables in a PostgreSQL database. Using this
> data I want to implement a database m
12 matches
Mail list logo
