Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 86EF69FA354; Fri, 13 Oct 2006 19:58:01 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 08806-09; Fri, 13 Oct 2006 22:57:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from davinci.ethosmedia.com (server227.ethosmedia.com [209.128.84.227]) by postgresql.org (Postfix) with ESMTP id 43BC89FB4C6; Fri, 13 Oct 2006 19:57:52 -0300 (ADT) X-EthosMedia-Virus-Scanned: no infections found Received: from [64.81.245.111] (account josh@agliodbs.com HELO [192.168.1.27]) by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 10323909; Fri, 13 Oct 2006 16:01:25 -0700 From: Josh Berkus Reply-To: josh@agliodbs.com Organization: Aglio Database Solutions To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Hints proposal Date: Fri, 13 Oct 2006 15:59:17 -0700 User-Agent: KMail/1.8 Cc: "Zeugswetter Andreas ADI SD" , "Jim C. Nasby" , pgsql-performance@postgresql.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610131559.18328.josh@agliodbs.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200610/274 X-Sequence-Number: 21403 Andreas, > I think we need to more precisely define the problems of our system with > point in time statistics > > -- no reaction to degree of other concurrent activity > -- no way to react to abnormal skew that only persists for a very short > duration > -- too late reaction to changing distribution (e.g. current date column > when a new year starts) > and the variant: too late adaption when a table is beeing filled > -- missing cost/selectivity estimates for several parts of the system How would we manage point-in-time statistics? How would we collect them & store them? I think this is an interesting idea, but very, very hard to do ... -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco