vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| 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 |
| |||
| 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...2/msg00307.php Your results may vary. If you see substantially different results then please post the particulars. -- Michael Fuhr ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org |
| ||||
| 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 > ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly |