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 1BA4F9DC9E3 for ; Tue, 10 Jan 2006 23:40:35 -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 70974-05 for ; Tue, 10 Jan 2006 23:40:39 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 3B25E9DC9D0 for ; Tue, 10 Jan 2006 23:40:31 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id k0B3eUgS007925; Tue, 10 Jan 2006 22:40:30 -0500 (EST) To: Simon Riggs cc: Matteo Beccati , Andrea Arcangeli , pgsql-performance@postgresql.org Subject: Re: NOT LIKE much faster than LIKE? In-reply-to: <1136936205.21025.507.camel@localhost.localdomain> 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> Comments: In-reply-to Simon Riggs message dated "Tue, 10 Jan 2006 23:36:45 +0000" Date: Tue, 10 Jan 2006 22:40:30 -0500 Message-ID: <7924.1136950830@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.08 required=5 tests=[AWL=0.080] X-Spam-Score: 0.08 X-Spam-Level: X-Archive-Number: 200601/97 X-Sequence-Number: 16575 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. regards, tom lane