pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
PG Statistics
5+ messages / 3 participants
[nested] [flat]

* PG Statistics
@ 2006-03-13 23:49  mcelroy, tim <tim.mcelroy@bostonstock.com>
  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-14 00:18  Michael Fuhr <mike@fuhr.org>
  parent: mcelroy, tim <tim.mcelroy@bostonstock.com>
  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-14 00:37  Steve Poe <spoe@sfnet.cc>
  parent: mcelroy, tim <tim.mcelroy@bostonstock.com>
  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