On Tue, 17 Jul 2018 11:03:08 +0200 Fabio Pardi <f.pardi@xxxxxxxxxxxx> wrote: > On 07/17/2018 10:21 AM, Jehan-Guillaume (ioguix) de Rorthais wrote: > > On Tue, 17 Jul 2018 10:11:50 +0200 > > > ...and check this one: https://github.com/OPMDG/check_pgactivity/ > > > > It uses bloat queries for tables and btree indexes Adrien Nayrat was > > pointing earlier in this thread. > > > > In fact, both queries in check_pgactivity were written because the bloat > > check in check_postgres was considering **all** fields were in **all*** > > indexes.. > > not accurately, since it is excluding a few things. > > from the docs: > 'Tables must have at least 10 pages, and indexes at least 15, before > they can be considered by this test.' well I agree with this. What the point of computing bloat for small objects? I would raise this way higher. > + you can include and exclude objects based on your taste, same as in > check_pgactivity. > > The only 'drawback' of check_postgres.pl is that it checks indexes and > tables's bloat in one go. (but: if your object's names are normalized, > it should not be difficult to include or exclude them) > I do not consider it a drawback, but you are free to pick your poison... Well, again, the btree approximation is quite large in check_postgres. I would not rely on it detect bloat quickly. **If this is still true**, as it considers all fields are in the index, the estimated index size might be veeeeery large compared to the real one. But, again, this is a few years I did not digg in this query, I mmight be wrong. > > Which is quite a large approximation...I don't know if this is still > > the case though. > > While i think both tools might fit Alessandro's purpose, please note > that check_pgactivity is **only** checking for btree indexes (which are > the default ones, and the proven-to-get-bloated-quickly) > > If I were you (both), I would monitor **all** indexes (and yes! tables > too), since one day you might realize it was actually a good idea to do so. I agree, we should monitor all indexes. If you have some formula to quickly estimate ideal size of a GIN, GiST, hash or sp-gist indexes, please share. But, unfortunately, as far as I know, this is way more complex than just summing the average size of the fields in the index :/
