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 CE9659DC959 for ; Mon, 2 Jan 2006 17:02:13 -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 26128-05 for ; Mon, 2 Jan 2006 17:02:14 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from floppy.pyrenet.fr (news.pyrenet.fr [194.116.145.2]) by postgresql.org (Postfix) with ESMTP id 7EEA89DC93F for ; Mon, 2 Jan 2006 17:02:11 -0400 (AST) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 4390F33A69; Mon, 2 Jan 2006 22:02:13 +0100 (MET) From: "Qingqing Zhou" X-Newsgroups: pgsql.hackers Subject: Re: Stats collector performance improvement Date: Mon, 2 Jan 2006 16:03:20 -0500 Organization: Hub.Org Networking Services Lines: 26 Message-ID: References: <200601021840.k02Ieed21704@candle.pha.pa.us> <11924.1136233224@sss.pgh.pa.us> X-Complaints-To: usenet@news.hub.org X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Original To: pgsql-hackers@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.159 required=5 tests=[AWL=0.159] X-Spam-Score: 0.159 X-Spam-Level: X-Archive-Number: 200601/76 X-Sequence-Number: 78180 "Tom Lane" wrote > > 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. > AFAICS if we can maintain the stats counts solid, then it may hurt performance dramatically. Think if we maintain pgstat_count_heap_insert()/pgstat_count_heap_delete() pretty well, then we get a replacement of count(*). To do so, I believe that will add another lock contention on the target table stats. Regards, Qingqing