X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 9139F9DC81E for ; Mon, 2 Jan 2006 16:20:26 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 03183-03 for ; Mon, 2 Jan 2006 16:20:27 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 6BF879DC80F for ; Mon, 2 Jan 2006 16:20:24 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id k02KKO5J011925; Mon, 2 Jan 2006 15:20:24 -0500 (EST) To: Bruce Momjian cc: Jan Wieck , pgsql-hackers@postgreSQL.org Subject: Re: Stats collector performance improvement In-reply-to: <200601021840.k02Ieed21704@candle.pha.pa.us> References: <200601021840.k02Ieed21704@candle.pha.pa.us> Comments: In-reply-to Bruce Momjian message dated "Mon, 02 Jan 2006 13:40:40 -0500" Date: Mon, 02 Jan 2006 15:20:24 -0500 Message-ID: <11924.1136233224@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.06 required=5 tests=[AWL=0.060] X-Spam-Score: 0.06 X-Spam-Level: X-Archive-Number: 200601/75 X-Sequence-Number: 78179 [ moving to -hackers ] Bruce Momjian writes: > I did some research on this because the numbers Tom quotes indicate there > is something wrong in the way we process stats_command_string > statistics. > [ ... proposed patch that seems pretty klugy to me ... ] I wonder whether we shouldn't consider something more drastic, like getting rid of the intermediate stats buffer process entirely. The original design for the stats communication code was based on the premise that it's better to drop data than to make backends wait on the stats collector. However, as things have turned out I think this notion is a flop: the people who are using stats at all want the stats to be reliable. We've certainly seen plenty of gripes from people who are unhappy that backend-exit messages got dropped, and anyone who's using autovacuum would really like the tuple update counts to be pretty solid too. If we abandoned the unreliable-communication approach, could we build something with less overhead? regards, tom lane