Tom Lane wrote:
> Bruce Momjian 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.
--
Bruce Mom
Bruce Momjian 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
---(end of
Bruce Momjian 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 irrelevant implem
Tom Lane wrote:
> Bruce Momjian 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 lev
Bruce Momjian 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; the fact that th
Tom Lane wrote:
> Bruce Momjian 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.
Why d
Bruce Momjian 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.
regards,
