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-08 10:08:33 |
Message-ID: | 1d4e0c10711080208n6c9875b4tf5882da3ced18532@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
Tom,
On Nov 8, 2007 12:14 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I've applied a patch that might help you:
> http://archives.postgresql.org/pgsql-committers/2007-11/msg00104.php
AFAICS, it doesn't seem to fix the problem. I just compiled
REL8_1_STABLE branch and I still has the following behaviour:
lbo=# ANALYZE cms_items;
ANALYZE
lbo=# explain analyze select * from cms_items where ancestors LIKE '1062/%';
QUERY PLAN
------------------------------------------------------------------------------------------------------------
Seq Scan on cms_items (cost=0.00..688.26 rows=1 width=103) (actual
time=0.009..22.258 rows=11326 loops=1)
Filter: ((ancestors)::text ~~ '1062/%'::text)
Total runtime: 29.835 ms
(3 rows)
lbo=# show lc_collate;
lc_collate
-------------
fr_FR.UTF-8
(1 row)
Do you see any reason why your patch doesn't change anything in this case?
Thanks.
--
Guillaume
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-11-08 10:38:03 | Re: A small rant about coding style for backend functions |
Previous Message | Heikki Linnakangas | 2007-11-08 09:21:50 | Re: Visibility map thoughts |
From | Date | Subject | |
---|---|---|---|
Next Message | Rafael Martinez | 2007-11-08 10:36:36 | Need to run CLUSTER to keep performance |
Previous Message | Mark Kirkwood | 2007-11-08 07:18:47 | Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1 |