From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> |
Cc: | pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Estimation problem with a LIKE clause containing a / |
Date: | 2007-11-07 16:58:49 |
Message-ID: | 18180.1194454729@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
"Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> writes:
> On 11/7/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2007-11-07 18:20:12 | Re: Visibility map thoughts |
Previous Message | Guillaume Smet | 2007-11-07 16:52:16 | Re: Estimation problem with a LIKE clause containing a / |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-11-07 23:14:08 | Re: Estimation problem with a LIKE clause containing a / |
Previous Message | Guillaume Smet | 2007-11-07 16:52:16 | Re: Estimation problem with a LIKE clause containing a / |