Обсуждение: Using stats_command_string for xact statistics

Поиск
Список
Период
Сортировка

Using stats_command_string for xact statistics

От
Bruce Momjian
Дата:
I know we said we don't want to add an additional GUC variable just to
control xact statistics, but I am thinking that using
stat_command_string isn't a logical variable to use because it is
unrelated to commutative statistics.

I am thinking using row and block-level statistics to turn on xact
statistics makes sense, but not to use stat_command_string for that
purpose. 

---------------------------------------------------------------------------

Bruce Momjian wrote:
> 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?  Is it a copy/paste error?
> 
> Patch attached for review.  The inclusion of pgstat_collect_querystring
> in these tests seems like a bug.
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

> Index: src/backend/postmaster/pgstat.c
> ===================================================================
> RCS file: /cvsroot/pgsql/src/backend/postmaster/pgstat.c,v
> retrieving revision 1.115
> diff -c -c -r1.115 pgstat.c
> *** src/backend/postmaster/pgstat.c    31 Dec 2005 19:39:10 -0000    1.115
> --- src/backend/postmaster/pgstat.c    1 Jan 2006 03:31:24 -0000
> ***************
> *** 810,817 ****
>       int            i;
>   
>       if (pgStatSock < 0 ||
> !         !(pgstat_collect_querystring ||
> !           pgstat_collect_tuplelevel ||
>             pgstat_collect_blocklevel))
>       {
>           /* Not reporting stats, so just flush whatever we have */
> --- 810,816 ----
>       int            i;
>   
>       if (pgStatSock < 0 ||
> !         !(pgstat_collect_tuplelevel ||
>             pgstat_collect_blocklevel))
>       {
>           /* Not reporting stats, so just flush whatever we have */
> ***************
> *** 1224,1231 ****
>   void
>   pgstat_count_xact_commit(void)
>   {
> !     if (!(pgstat_collect_querystring ||
> !           pgstat_collect_tuplelevel ||
>             pgstat_collect_blocklevel))
>           return;
>   
> --- 1223,1229 ----
>   void
>   pgstat_count_xact_commit(void)
>   {
> !     if (!(pgstat_collect_tuplelevel ||
>             pgstat_collect_blocklevel))
>           return;
>   
> ***************
> *** 1256,1263 ****
>   void
>   pgstat_count_xact_rollback(void)
>   {
> !     if (!(pgstat_collect_querystring ||
> !           pgstat_collect_tuplelevel ||
>             pgstat_collect_blocklevel))
>           return;
>   
> --- 1254,1260 ----
>   void
>   pgstat_count_xact_rollback(void)
>   {
> !     if (!(pgstat_collect_tuplelevel ||
>             pgstat_collect_blocklevel))
>           return;
>   

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: Using stats_command_string for xact statistics

От
Tom Lane
Дата:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I know we said we don't want to add an additional GUC variable just to
> control xact statistics, but I am thinking that using
> stat_command_string isn't a logical variable to use because it is
> unrelated to commutative statistics.

> I am thinking using row and block-level statistics to turn on xact
> statistics makes sense, but not to use stat_command_string for that
> purpose. 

I don't see any strong logic to that, and changing the behavior just
for the sake of change doesn't appeal to me...
        regards, tom lane


Re: Using stats_command_string for xact statistics

От
Bruce Momjian
Дата:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I know we said we don't want to add an additional GUC variable just to
> > control xact statistics, but I am thinking that using
> > stat_command_string isn't a logical variable to use because it is
> > unrelated to commutative statistics.
> 
> > I am thinking using row and block-level statistics to turn on xact
> > statistics makes sense, but not to use stat_command_string for that
> > purpose. 
> 
> I don't see any strong logic to that, and changing the behavior just
> for the sake of change doesn't appeal to me...

OK, additional sentence added, and paragraph split into two:

!    Additionally, per-database transaction commit and abort statistics
!    are collected if any of these parameters are set.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073