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 6DF3D9DC94A for ; Mon, 9 Jan 2006 23:47:21 -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 92381-04 for ; Mon, 9 Jan 2006 23:47:26 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from opteron.random (unknown [217.133.42.200]) by postgresql.org (Postfix) with ESMTP id E5EC49DC93B for ; Mon, 9 Jan 2006 23:47:18 -0400 (AST) Received: by opteron.random (Postfix, from userid 500) id 1DF021C17B1; Tue, 10 Jan 2006 04:47:21 +0100 (CET) Date: Tue, 10 Jan 2006 04:47:21 +0100 From: Andrea Arcangeli To: Tom Lane Cc: pgsql-performance@postgresql.org Subject: Re: NOT LIKE much faster than LIKE? Message-ID: <20060110034721.GC20168@opteron.random> References: <20060110014447.GB18474@opteron.random> <24021.1136858688@sss.pgh.pa.us> <20060110022303.GA20168@opteron.random> <24372.1136861684@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24372.1136861684@sss.pgh.pa.us> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.12 required=5 tests=[AWL=0.120] X-Spam-Score: 0.12 X-Spam-Level: X-Archive-Number: 200601/79 X-Sequence-Number: 16557 On Mon, Jan 09, 2006 at 09:54:44PM -0500, Tom Lane wrote: > Extrapolating from the observation that the heuristics don't work well > on your data to the conclusion that they don't work for anybody is not > good logic. Replacing that code with a flat 50% is not going to happen > (or if it does, I'll be sure to send the mob of unhappy users waving > torches and pitchforks to your door not mine ;-)). I'm not convinced but of course I cannot exclude that some people may be depending on this very heuristic. But I consider this being bug-compatible, I've an hard time to be convinced that such heuristic isn't going to bite other people like it did with me. > I did just think of something we could improve though. The pattern > selectivity code doesn't make any use of the statistics about "most > common values". For a constant pattern, we could actually apply the > pattern test with each common value and derive answers that are exact > for the portion of the population represented by the most-common-values > list. If the MCV list covers a large fraction of the population then > this would be a big leg up in accuracy. Dunno if that applies to your > particular case or not, but it seems worth doing ... Fixing this with proper stats would be great indeed. What would be the most common value for the kernel_version? You can see samples of the kernel_version here http://klive.cpushare.com/2.6.15/ . That's the string that is being searched against both PREEMPT and SMP. BTW, I also run a LIKE '%% SMP %%' a NOT LIKE '%% SMP %%' but that runs fine, probably because as you said in the first email PREEMPT is long but SMP is short. Thanks!