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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

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