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 3268D9DC865 for ; Wed, 11 Jan 2006 05:07:49 -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 27220-03 for ; Wed, 11 Jan 2006 05:07:50 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by postgresql.org (Postfix) with ESMTP id EF9209DC813 for ; Wed, 11 Jan 2006 05:07:46 -0400 (AST) Received: from [192.168.0.3] (unknown [84.12.184.6]) by smtp.nildram.co.uk (Postfix) with ESMTP id 22DA626A8DC; Wed, 11 Jan 2006 09:07:44 +0000 (GMT) Subject: Re: NOT LIKE much faster than LIKE? From: Simon Riggs To: Tom Lane Cc: Matteo Beccati , Andrea Arcangeli , pgsql-performance@postgresql.org In-Reply-To: <7924.1136950830@sss.pgh.pa.us> References: <20060110014447.GB18474@opteron.random> <24021.1136858688@sss.pgh.pa.us> <20060110022303.GA20168@opteron.random> <24372.1136861684@sss.pgh.pa.us> <43C3799D.5030103@beccati.com> <1625.1136915395@sss.pgh.pa.us> <1136930796.21025.486.camel@localhost.localdomain> <6398.1136931685@sss.pgh.pa.us> <1136936205.21025.507.camel@localhost.localdomain> <7924.1136950830@sss.pgh.pa.us> Content-Type: text/plain Date: Wed, 11 Jan 2006 09:07:45 +0000 Message-Id: <1136970465.21025.527.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.058 required=5 tests=[AWL=0.058] X-Spam-Score: 0.058 X-Spam-Level: X-Archive-Number: 200601/105 X-Sequence-Number: 16583 On Tue, 2006-01-10 at 22:40 -0500, Tom Lane wrote: > Simon Riggs writes: > > I meant use the same sampling approach as I was proposing for ANALYZE, > > but do this at plan time for the query. That way we can apply the > > function directly to the sampled rows and estimate selectivity. > > I think this is so unlikely to be a win as to not even be worth spending > any time discussing. The extra planning time across all queries will > vastly outweigh the occasional improvement in plan choice for some > queries. Extra planning time would be bad, so clearly we wouldn't do this when we already have relevant ANALYZE statistics. I would suggest we do this only when all of these are true - when accessing more than one table, so the selectivity could effect a join result - when we have either no ANALYZE statistics, or ANALYZE statistics are not relevant to estimating selectivity, e.g. LIKE - when access against the single table in question cannot find an index to use from other RestrictInfo predicates I imagined that this would also be controlled by a GUC, dynamic_sampling which would be set to zero by default, and give a measure of sample size to use. (Or just a bool enable_sampling = off (default)). This is mentioned now because the plan under consideration in this thread would be improved by this action. It also isn't a huge amount of code to get it to work. Best Regards, Simon Riggs