Re: pg_reset_stats + cache I/O %

Поиск
Список
Период
Сортировка
От mcelroy, tim
Тема Re: pg_reset_stats + cache I/O %
Дата
Msg-id 0C4841B42F87D51195BD00B0D020F5CB044B2431@morpheus.bostonstock.com
обсуждение исходный текст
Ответ на pg_reset_stats + cache I/O %  ("mcelroy, tim" <tim.mcelroy@bostonstock.com>)
Ответы Re: pg_reset_stats + cache I/O %  ("Jim C. Nasby" <jnasby@pervasive.com>)
Список pgsql-performance

I actually need this info as I was tasked by management to provide it.  Not sure if they understand that or not, I do but management does like to see how well the system and its components are performing.  Also, I would utilize these results to test any cache tuning changes I may make. 

Tim

 -----Original Message-----
From:   Jim C. Nasby [mailto:jnasby@pervasive.com]
Sent:   Wednesday, March 08, 2006 1:28 PM
To:     mcelroy, tim
Cc:     'Tom Lane'; 'pgsql-performance@postgresql.org'
Subject:        Re: [PERFORM] pg_reset_stats + cache I/O %

Out of curiosity, why do you want this info? More important, do the
folks who are looking at this understand that a key part of PostgreSQL's
tuning strategy is to let the OS handle the bulk of the caching?

On Wed, Mar 08, 2006 at 08:59:51AM -0500, mcelroy, tim wrote:
> Thanks Tom, sorry I neglected to copy the list on my previous email.....
>
> Does this query make sense and is it valid for an accurate cache % hit ratio
> for the entire DB?  I would assume I could use the same logic with other
> views such as pg_stat_user_tables to get a per table ratio?
>
> SELECT 100 - round((blks_hit::numeric / (blks_hit::numeric +
> blks_read::numeric)) * 100,2)
> AS "Cache % Hit"
> FROM pg_stat_database
> WHERE datname = 'Fix1';
>
> <RETURNS>
>
> Cache % Hit
> --------------------
>        98.06
> (1 row)
>
> Thank you,
> Tim
>
>  -----Original Message-----
> From:         Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Tuesday, March 07, 2006 2:37 PM
> To:   mcelroy, tim
> Cc:   'pgsql-performance@postgresql.org'
> Subject:      Re: [PERFORM] pg_reset_stats + cache I/O %
>
> "mcelroy, tim" <tim.mcelroy@bostonstock.com> writes:
> > ERROR:  function round(double precision, integer) does not exist
>
> Try coercing to numeric instead of float.  Also, it'd be a good idea to
> put that coercion outside the sum()'s instead of inside --- summing
> bigints is probably noticeably faster than summing numerics.
>
>                       regards, tom lane

--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

В списке pgsql-performance по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: pg_reset_stats + cache I/O %
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Is good idea an array of 365 elements in a cell of a table, in order to perform searchs?