pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedimpact of stats_command_string
3+ messages / 3 participants
[nested] [flat]
* impact of stats_command_string
@ 2005-10-20 20:33 jnevans@gmail.com
2005-10-25 16:04 ` Re: impact of stats_command_string Michael Fuhr <mike@fuhr.org>
0 siblings, 1 reply; 3+ messages in thread
From: jnevans@gmail.com @ 2005-10-20 20:33 UTC (permalink / raw)
To: 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.
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: impact of stats_command_string
2005-10-20 20:33 impact of stats_command_string jnevans@gmail.com
@ 2005-10-25 16:04 ` Michael Fuhr <mike@fuhr.org>
0 siblings, 0 replies; 3+ messages in thread
From: Michael Fuhr @ 2005-10-25 16:04 UTC (permalink / raw)
To: jnevans@gmail.com; +Cc: pgsql-performance
On Thu, Oct 20, 2005 at 01:33:07PM -0700, jnevans@gmail.com wrote:
> 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?
Do you really need to be doing "massive data INSERTs"? Can you use
COPY, which is much more efficient for bulk loads?
http://www.postgresql.org/docs/8.0/interactive/populate.html
--
Michael Fuhr
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: impact of stats_command_string
@ 2005-10-25 17:02 Merlin Moncure <merlin.moncure@rcsonline.com>
0 siblings, 0 replies; 3+ messages in thread
From: Merlin Moncure @ 2005-10-25 17:02 UTC (permalink / raw)
To: jnevans@gmail.com; +Cc: 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
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2005-10-25 17:02 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-10-20 20:33 impact of stats_command_string jnevans@gmail.com
2005-10-25 16:04 ` Michael Fuhr <mike@fuhr.org>
2005-10-25 17:02 Re: impact of stats_command_string Merlin Moncure <merlin.moncure@rcsonline.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