X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id B5B679DCC9D for ; Fri, 16 Dec 2005 01:45:09 -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 12899-09 for ; Fri, 16 Dec 2005 01:45:08 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by postgresql.org (Postfix) with ESMTP id ABE159DCCDF for ; Fri, 16 Dec 2005 01:45:07 -0400 (AST) Received: from sysexperts.com (c-67-170-228-241.hsd1.ca.comcast.net[67.170.228.241]) by comcast.net (rwcrmhc12) with ESMTP id <20051216054458014008icv0e>; Fri, 16 Dec 2005 05:45:03 +0000 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by filer with local; Thu, 15 Dec 2005 21:44:58 -0800 id 18325A61.43A2545A.000011F5 Date: Thu, 15 Dec 2005 21:44:58 -0800 From: Kevin Brown To: pgsql-performance@postgresql.org Subject: Re: How much expensive are row level statistics? Message-ID: <20051216054457.GC691@filer> Mail-Followup-To: Kevin Brown , pgsql-performance@postgresql.org References: <6EE64EF3AB31D5448D0007DD34EEB3417DDAC9@Herge.rcsinc.local> <2506.1134428461@sss.pgh.pa.us> <20051213010751.GA63416@winnie.fuhr.org> <1667.1134444045@sss.pgh.pa.us> <20051215234448.GA47382@winnie.fuhr.org> <18416.1134691599@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <18416.1134691599@sss.pgh.pa.us> Organization: Frobozzco International User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200512/388 X-Sequence-Number: 16209 Tom Lane wrote: > Michael Fuhr writes: > > Does the backend support, or could it be easily modified to support, > > a mechanism that would post the command string after a configurable > > amount of time had expired, and then continue processing the query? > > Not really, unless you want to add the overhead of setting a timer > interrupt for every query. Which is sort of counterproductive when > the motivation is to reduce overhead ... > > (It might be more or less free if you have statement_timeout set, since > there would be a setitimer call anyway. But I don't think that's the > norm.) Actually, it's probably not necessary to set the timer at the beginning of every query. It's probably sufficient to just have it go off periodically, e.g. once every second, and thus set it when the timer goes off. And the running command wouldn't need to be re-posted if it's the same as last time around. Turn off the timer if the connection is idle now and was idle last time around (or not, if there's no harm in having the timer running all the time), turn it on again at the start of the next transaction. In essence, the backend would be "polling" itself every second or so and recording its state at that time, rather than on every transaction. Assuming that doing all that wouldn't screw something else up... -- Kevin Brown kevin@sysexperts.com