Skip site navigation (1) Skip section navigation (2)

Re: impact of stats_command_string

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: <jnevans(at)gmail(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: impact of stats_command_string
Date: 2005-10-25 17:02:20
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3417DD69F@Herge.rcsinc.local (view raw or flat)
Thread:
Lists: pgsql-performance
> If I turn on stats_command_string, how much impact would it have on
> PostgreSQL server's performance during a period of massive data
> INSERTs?  I know that the answer to the question I'm asking will
> largely depend upon different factors so I would like to know in which
> situations it would be negligible or would have a signifcant impact.

First of all, we have to assume your writes are buffered in some way or
you are using transactions, or you will likely be i/o bound (or you have
a super fast disk setup).

Assuming that, I can tell you from experience on win32 that
stats_command_string can be fairly expensive for certain types of access
patterns.  What patterns?

1. If your ratio of queries to records involved is low.
2. If you are accessing data in a very quick way, for example via
prepared statements over a LAN
3. Your volume of queries is very high.

In these cases, the cost is high.  stats_command_string can add a
fractional millisecond ( ~.2  in my setup ) to statement latency and as
much as double cpu time in extreme cases...you are warned.  You may want
to turn it off before doing bulk loads or lengthy record iterations.

Merlin

pgsql-performance by date

Next:From: Tom LaneDate: 2005-10-25 18:01:04
Subject: Re: Why Index is not working on date columns.
Previous:From: Michael FuhrDate: 2005-10-25 16:04:08
Subject: Re: impact of stats_command_string

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group