Re: Estimation problem with a LIKE clause containing a /

From: "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Estimation problem with a LIKE clause containing a /
Date: 2007-11-07 16:52:16
Message-ID: 1d4e0c10711070852hfc8aaf2o6eb0cdace2efc9b5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

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.

> > Version is PostgreSQL 8.1.8 on i686-redhat-linux-gnu,
>
> You'd probably get better results with 8.2, which has a noticeably
> smarter LIKE-estimator, at least for histogram sizes of 100 or more.

It's not really possible to upgrade this application to 8.2 for now.
It's a very old app based on the thing formerly called as Red Hat WAF
and now known as APLAWS and validating WAF and this application with
8.2 will take quite some time. Moreover the db is big and we can't
afford the downtime of a migration.

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?

Thanks,

--
Guillaume

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-11-07 16:58:49 Re: Estimation problem with a LIKE clause containing a /
Previous Message Tom Lane 2007-11-07 16:34:52 Re: Estimation problem with a LIKE clause containing a /

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2007-11-07 16:58:49 Re: Estimation problem with a LIKE clause containing a /
Previous Message Tom Lane 2007-11-07 16:34:52 Re: Estimation problem with a LIKE clause containing a /