Bruce Momjian pgman@candle.pha.pa.us writes:
Does anyone know why we test for pgstat_collect_querystring in routines
that obviously dump only block and row-level statistics and database
commit/rollback total?
Because we want commits/rollbacks to be counted if any of them are on.
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Does anyone know why we test for pgstat_collect_querystring in routines
that obviously dump only block and row-level statistics and database
commit/rollback total?
Because we want commits/rollbacks to be counted if any of them
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Because we want commits/rollbacks to be counted if any of them are on.
Why do we want commits/rollbacks counted if we only have command string
enabled?
Why not? Those counts are not either tuple level or block level
operations;
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Because we want commits/rollbacks to be counted if any of them are on.
Why do we want commits/rollbacks counted if we only have command string
enabled?
Why not? Those counts are not either tuple level or
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Barring making a fourth GUC variable to control them (which seems like
overkill), I think it's a reasonably sane definition to say we count
these if any stats are being collected. Doing what you propose would
simply expose an
Bruce Momjian pgman@candle.pha.pa.us writes:
The good news is I found out why stat_command_string is causing such a
large performance hit. I will post tonight or tomorrow on it.
There's more to it than just a lot of messages being sent?
regards, tom lane
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
The good news is I found out why stat_command_string is causing such a
large performance hit. I will post tonight or tomorrow on it.
There's more to it than just a lot of messages being sent?
You bet! I will try to post soon.
Joachim Wieland wrote:
I propose the attached patch for the TODO item:
* %Allow pooled connections to list all prepared queries
Attached is a revised version of this patch, based on some improvements
sent to me offlist by Joachim, as well as some code review and fixes by
myself. Changes:
Neil Conway [EMAIL PROTECTED] writes:
The docs need some improvement, but I'm not aware of any major remaining
issues with the patch.
I object VERY strongly to the part of the patch that inserts a
deparse_query_list() call into exec_parse_message(). That is not a
cheap operation, and imposing
