On Tue, 12 Aug 2003, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > but pgstat_initstats() caught my eye. This gets called about 6 times per
> > insert (I did 100000 inserts) and the major cost appears to relate to the
> > linear pgStatTabstatMessages. The comparative performance of
> > hash_search() suggests that pgStatTabstatMessages may benefit from use of
> > a hash. However, it seems unreasonable that we're doing work at all in
> > pgstat_initstats() if the user is not interested in query/block/tuple
> > stats.
>
> The coding in the search loop could perhaps be tightened a little, but
> I'd think the last point should be addressed by dropping out via the
> "no_stats" exit if stats aren't being gathered.
>
> I doubt a hash is worth maintaining, because the active tabstat entries
> should only be for tables that are being touched in the current command
> (thus, there are not more than six in your example). I'm not sure why
> it takes so much time to look through six entries though ...
Neither. I might look into it further later, but here's a patch to exit
out of pgstat_initstats() if we're not collecting stats (attached).
Thanks,
Gavin
Index: src/backend/postmaster/pgstat.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql-server/src/backend/postmaster/pgstat.c,v
retrieving revision 1.42
diff -2 -c -r1.42 pgstat.c
*** src/backend/postmaster/pgstat.c 4 Aug 2003 00:43:21 -0000 1.42
--- src/backend/postmaster/pgstat.c 11 Aug 2003 02:14:53 -0000
***************
*** 829,832 ****
--- 829,838 ----
stats->index_scan_counted = FALSE;
+ if (!pgstat_collect_querystring && !pgstat_collect_tuplelevel &&
+ !pgstat_collect_blocklevel) {
+ stats->no_stats = TRUE;
+ return;
+ }
+
if (pgStatSock < 0)
{
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
