[check_postgres] bloat check doesn't work with --include

[Greg Sabino Mullane]

On 07/21/2009 09:05 PM, Jeff Frost wrote:
> Looks like there's a bug with using --include=<table> and the bloat check:
..
> But, in fact there is a table named bar:

This one's a little tricky, as it could be a number of things.

0. The table doesn't exist. :)
1. The table has never been analyzed (= no rows in pg_stats)
2. The table has no rows, as still no rows in pg_stats)
3. It does not meet the minimum criteria for bloat. Right now
   it is at least 1 page of bloat for tables, and at least 11
   pages of bloat for indexes.
4. It was a victim of the ORDER BY .. LIMIT gotcha I just fixed,
   committed and pushed. :)

About #4: rather than report back the entire database worth of
relations, the bloat query has a LIMIT on it (set to --perflimit,
which defaults to 10). I changed it so that if --include is used,
the LIMIT is simply removed. Maybe we shouldn't have the limit at
all, and filter another way, similar to the recent check_backends
fix. Too tired to tackle that at the moment. Let me know if one
of the 5 choices above does not apply to your situation.


-- 
Greg Sabino Mullane greg at endpoint.com
End Point Corporation
PGP Key: 0x14964AC8

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 226 bytes
Desc: OpenPGP digital signature
Url : https://mail.endcrypt.com/pipermail/check_postgres/attachments/20090722/463f9422/attachment.bin