Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id E27C72E0035 for ; Tue, 8 Apr 2008 05:55:16 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 10641-10 for ; Tue, 8 Apr 2008 05:55:09 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.162.198]) by developer.postgresql.org (Postfix) with ESMTP id 9C32F2E004A for ; Tue, 8 Apr 2008 05:55:05 -0300 (ADT) Received: from mailsrv.i.zmi.at (h081217054243.dyn.cm.kabsi.at [81.217.54.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailsrv.i.zmi.at", Issuer "mailsrv.i.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id B3C42EA2 for ; Tue, 8 Apr 2008 10:55:02 +0200 (CEST) Received: from saturn.i.zmi.at (saturn.i.zmi.at [10.0.0.2]) by mailsrv.i.zmi.at (Postfix) with ESMTP id C7B05BFBB for ; Tue, 8 Apr 2008 10:55:01 +0200 (CEST) From: Michael Monnerie Organization: it-management http://it-management.at To: pgsql-admin@postgresql.org Subject: Re: Tuning Date: Tue, 8 Apr 2008 10:55:02 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) References: <6F737A76-FC25-4876-A6E0-163B87ECFAB0@indiana.edu> <200804080917.27689@zmi.at> <47FB20D4.3050504@gmail.com> In-Reply-To: <47FB20D4.3050504@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1290577.odDdKSKeRH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200804081055.02620@zmi.at> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.026 tagged_above=0 required=5 tests=AWL=0.026 X-Spam-Level: X-Archive-Number: 200804/66 X-Sequence-Number: 28830 --nextPart1290577.odDdKSKeRH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Dienstag, 8. April 2008 paul rivers wrote: > I don't see a direct way to monitor bloat from pg_stat*. =A0 If I'm > wrong, please set me straight. > > For example, monitoring index bloat would involve deciding how many > pages an index would ideally consume, based on either sampling the > table yourself or raiding stats, and making assumptions. =A0Then you'd > compare to actual (or approximated actual) and decide if you were > within whatever threshold you think is OK. If there's no rule of thumb, how could you manually decide on actions,=20 other than by reading from a crystal ball? Also, if there are no tools, almost no admin can/will do anything.=20 Except for the specialist having too much free time to dig into the db=20 just for fun and reading tons of pg_stat* tables and values *g* As most won't have that funny time, tools which show possible problems=20 or performance losses would greatly help. On Dienstag, 8. April 2008 Jeff Frost wrote: > I don't know about rrd graphing it, but there are some great nagios > plugins for this at http://bucardo.org/nagios > > You could have a look at the queries used in those and roll your own > mrtg plugins. If you do, please share. Thank you. I'll have a look at that nagios plugins. mfg zmi =2D-=20 // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0676/846 914 666 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: www.keyserver.net Key-ID: 1C1209B4 --nextPart1290577.odDdKSKeRH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBH+zLmzhSR9xwSCbQRAplPAJ9DJMO5NtvleM3XhCu67lsYqXtv0ACeICp9 so70PECLUIYmtI0t0CYTZHA= =H1YE -----END PGP SIGNATURE----- --nextPart1290577.odDdKSKeRH--