pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedPG Statistics
5+ messages / 3 participants
[nested] [flat]
* PG Statistics
@ 2006-03-13 23:49 mcelroy, tim <tim.mcelroy@bostonstock.com>
2006-03-14 00:18 ` Re: PG Statistics Michael Fuhr <mike@fuhr.org>
2006-03-14 00:37 ` Re: PG Statistics Steve Poe <spoe@sfnet.cc>
0 siblings, 2 replies; 5+ messages in thread
From: mcelroy, tim @ 2006-03-13 23:49 UTC (permalink / raw)
To: pgsql-performance
Good evening,
Does anyone know how much of a performance hit turning stats_block_level and
stats_row_level on will incur? Do both need to be on to gather cache
related statistics? I know the annotated_conf_80 document states to only
turn them on for debug but if they're not that performance intensive I
cannot see the harm.
Thank you,
Tim McElroy
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: PG Statistics
2006-03-13 23:49 PG Statistics mcelroy, tim <tim.mcelroy@bostonstock.com>
@ 2006-03-14 00:18 ` Michael Fuhr <mike@fuhr.org>
1 sibling, 0 replies; 5+ messages in thread
From: Michael Fuhr @ 2006-03-14 00:18 UTC (permalink / raw)
To: mcelroy, tim <tim.mcelroy@bostonstock.com>; +Cc: pgsql-performance
On Mon, Mar 13, 2006 at 06:49:39PM -0500, mcelroy, tim wrote:
> Does anyone know how much of a performance hit turning stats_block_level and
> stats_row_level on will incur? Do both need to be on to gather cache
> related statistics? I know the annotated_conf_80 document states to only
> turn them on for debug but if they're not that performance intensive I
> cannot see the harm.
I ran some tests a few months ago and found that stats_command_string
had a significant impact, whereas stats_block_level and stats_row_level
were almost negligible. Here are my test results:
http://archives.postgresql.org/pgsql-performance/2005-12/msg00307.php
Your results may vary. If you see substantially different results
then please post the particulars.
--
Michael Fuhr
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: PG Statistics
2006-03-13 23:49 PG Statistics mcelroy, tim <tim.mcelroy@bostonstock.com>
@ 2006-03-14 00:37 ` Steve Poe <spoe@sfnet.cc>
1 sibling, 0 replies; 5+ messages in thread
From: Steve Poe @ 2006-03-14 00:37 UTC (permalink / raw)
To: mcelroy, tim <tim.mcelroy@bostonstock.com>; +Cc: pgsql-performance
Tim,
When I have done ODBC load tests with stats_block_level enabled on (20
mins. per test), I've seen about 3-4% performance hit. Your mileage may
vary.
Steve Poe
On Mon, 2006-03-13 at 18:49 -0500, mcelroy, tim wrote:
> Good evening,
>
> Does anyone know how much of a performance hit turning
> stats_block_level and stats_row_level on will incur? Do both need to
> be on to gather cache related statistics? I know the
> annotated_conf_80 document states to only turn them on for debug but
> if they're not that performance intensive I cannot see the harm.
>
> Thank you,
> Tim McElroy
>
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: PG Statistics
@ 2006-03-14 13:50 mcelroy, tim <tim.mcelroy@bostonstock.com>
0 siblings, 0 replies; 5+ messages in thread
From: mcelroy, tim @ 2006-03-14 13:50 UTC (permalink / raw)
To: Michael Fuhr <mike@fuhr.org>; +Cc: pgsql-performance
Thank you for the insight Michael. I'll be performing some tests with the
various setting on/off this week and will post the results.
Tim
-----Original Message-----
From: Michael Fuhr [mailto:mike@fuhr.org]
Sent: Monday, March 13, 2006 7:19 PM
To: mcelroy, tim
Cc: 'pgsql-performance@postgresql.org'
Subject: Re: [PERFORM] PG Statistics
On Mon, Mar 13, 2006 at 06:49:39PM -0500, mcelroy, tim wrote:
> Does anyone know how much of a performance hit turning stats_block_level
and
> stats_row_level on will incur? Do both need to be on to gather cache
> related statistics? I know the annotated_conf_80 document states to only
> turn them on for debug but if they're not that performance intensive I
> cannot see the harm.
I ran some tests a few months ago and found that stats_command_string
had a significant impact, whereas stats_block_level and stats_row_level
were almost negligible. Here are my test results:
http://archives.postgresql.org/pgsql-performance/2005-12/msg00307.php
Your results may vary. If you see substantially different results
then please post the particulars.
--
Michael Fuhr
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: PG Statistics
@ 2006-03-14 13:51 mcelroy, tim <tim.mcelroy@bostonstock.com>
0 siblings, 0 replies; 5+ messages in thread
From: mcelroy, tim @ 2006-03-14 13:51 UTC (permalink / raw)
To: Steve Poe <spoe@sfnet.cc>; +Cc: pgsql-performance
Thanks you Steve. As mentioned in my other reply to Michael Fuhr I'll post
the results from tests to be performed this week.
Tim
-----Original Message-----
From: Steve Poe [mailto:spoe@sfnet.cc]
Sent: Monday, March 13, 2006 7:38 PM
To: mcelroy, tim
Cc: 'pgsql-performance@postgresql.org'
Subject: Re: [PERFORM] PG Statistics
Tim,
When I have done ODBC load tests with stats_block_level enabled on (20
mins. per test), I've seen about 3-4% performance hit. Your mileage may
vary.
Steve Poe
On Mon, 2006-03-13 at 18:49 -0500, mcelroy, tim wrote:
> Good evening,
>
> Does anyone know how much of a performance hit turning
> stats_block_level and stats_row_level on will incur? Do both need to
> be on to gather cache related statistics? I know the
> annotated_conf_80 document states to only turn them on for debug but
> if they're not that performance intensive I cannot see the harm.
>
> Thank you,
> Tim McElroy
>
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2006-03-14 13:51 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-03-13 23:49 PG Statistics mcelroy, tim <tim.mcelroy@bostonstock.com>
2006-03-14 00:18 ` Michael Fuhr <mike@fuhr.org>
2006-03-14 00:37 ` Steve Poe <spoe@sfnet.cc>
2006-03-14 13:50 Re: PG Statistics mcelroy, tim <tim.mcelroy@bostonstock.com>
2006-03-14 13:51 Re: PG Statistics mcelroy, tim <tim.mcelroy@bostonstock.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox