Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id E4F1D9FCB6B
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed,  7 Nov 2007 12:59:11 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 22230-06-5
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed,  7 Nov 2007 12:58:21 -0400 (AST)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 3E1A49FCB87
	for <pgsql-performance@postgresql.org>;
	Wed,  7 Nov 2007 12:58:53 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id lA7GwnjC018181;
	Wed, 7 Nov 2007 11:58:50 -0500 (EST)
To: "Guillaume Smet" <guillaume.smet@gmail.com>
cc: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Estimation problem with a LIKE clause containing a / 
In-reply-to: <1d4e0c10711070852hfc8aaf2o6eb0cdace2efc9b5@mail.gmail.com> 
References: <1d4e0c10711070453q214f089cpd144cbb5193d3c4f@mail.gmail.com>
	<17767.1194453292@sss.pgh.pa.us>
	<1d4e0c10711070852hfc8aaf2o6eb0cdace2efc9b5@mail.gmail.com>
Comments: In-reply-to "Guillaume Smet" <guillaume.smet@gmail.com>
	message dated "Wed, 07 Nov 2007 17:52:16 +0100"
Date: Wed, 07 Nov 2007 11:58:49 -0500
Message-ID: <18180.1194454729@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200711/84
X-Sequence-Number: 27499

"Guillaume Smet" <guillaume.smet@gmail.com> writes:
> On 11/7/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmmm ... what locale are you working in?  I notice that the range
>> estimator for this pattern would be "ancestors >= '1062/' AND
>> ancestors < '10620'", which will do the right thing in C locale
>> but maybe not so much elsewhere.

> Sorry for not having mentioned it before. Locale is UTF-8.

I wanted the locale (lc_collate), not the encoding.

> I suppose my best bet is to remove the pg_statistic line and to set
> the statistics to 0 for this column so that the stats are never
> generated again for this column?

That would optimize this particular query and probably pessimize
a lot of others.  I have another LIKE-estimation bug to go look at
today too; let me see if this one is fixable or not.

			regards, tom lane