Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 5BA676503A6 for ; Fri, 12 Dec 2008 12:44:19 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 05730-02 for ; Fri, 12 Dec 2008 12:44:05 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail136073.authsmtp.co.uk (outmail136073.authsmtp.co.uk [62.13.136.73]) by mail.postgresql.org (Postfix) with ESMTP id C76FD64FCAB for ; Fri, 12 Dec 2008 12:44:04 -0400 (AST) Received: from mail-c188.authsmtp.com (mail-c188.authsmtp.com [62.13.128.25]) by punt9.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id mBCGhJLV048979; Fri, 12 Dec 2008 16:43:19 GMT Received: from [192.168.0.3] (85-211-226-82.dyn.gotadsl.co.uk [85.211.226.82]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id mBCGhIcg048708; Fri, 12 Dec 2008 16:43:18 GMT Subject: Re: benchmarking the query planner From: Simon Riggs To: Tom Lane Cc: Gregory Stark , Robert Haas , Kevin Grittner , "jd@commandprompt.com" , Josh Berkus , Greg Smith , pgsql-hackers@postgresql.org In-Reply-To: <6558.1229098576@sss.pgh.pa.us> References: <603c8f070812061019r5aca3aajeaa5493b11c5feff@mail.gmail.com> <603c8f070812092025k6325e0fcud001b205a507a634@mail.gmail.com> <4313.1228931932@sss.pgh.pa.us> <603c8f070812101828p1bd7df49yb8c916adedb49fe1@mail.gmail.com> <9565.1229018968@sss.pgh.pa.us> <1229033073.13078.179.camel@hp_dx2400_1> <87ej0etkfh.fsf@oxford.xeocode.com> <1229039044.13078.193.camel@hp_dx2400_1> <4136ffa0812111823u645b6ec9wdca60b3da4b00499@mail.gmail.com> <1229072675.13078.196.camel@hp_dx2400_1> <603c8f070812120344m67ef2c1fs41806cfb4ff9e396@mail.gmail.com> <1229093975.13078.275.camel@ebony.2ndQuadrant> <87tz99s7bu.fsf@oxford.xeocode.com> <6558.1229098576@sss.pgh.pa.us> Content-Type: text/plain Date: Fri, 12 Dec 2008 16:43:01 +0000 Message-Id: <1229100181.8673.32.camel@ebony.2ndQuadrant> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: faf516c9-c86b-11dd-aecc-001871e930f4 X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksafhtFaQdbaVxS HGQLW1xEUVt7XWB/ agIfZQBDYEtPQQdo VlZBQE1QEQdtHhxP W2xtJUELJFJGfHZ3 ZU4sXHBcXQosJBB4 Q0gHHHBVbWEydWEe BBRFJlYHIx5Kfh5N bVEqXXANN2FJBC9q VzwTFhsSEA9kHWxf TwcGLVcbW0UKGDF0 WxAPVSwyEFcUDz03 JhogJ0R0 X-Authentic-SMTP: 61633235383639.cat.dmpriest.net.uk:1378/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200812/953 X-Sequence-Number: 129582 On Fri, 2008-12-12 at 11:16 -0500, Tom Lane wrote: > If you want ANALYZE to be cheap then you simply don't get to have > a trustworthy value of ndistinct. Understood, but a cheap ANALYZE isn't always a higher priority than all other considerations. Solutions can also include * allowing user to note that we would actually like to scan the whole table (stats_target = -2?) * manual mechanism for setting ndistinct that doesn't keep getting overwritten by subsequent ANALYZEs * have the executor do non-transactional update of the value of ndistinct if it ever builds a hash table that is larger than expected (simple learning optimizer action) -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support