Re: LIKE conditions in PGSQL very, very slow!

From: Alban Hertroys <alban(at)magproductions(dot)nl>
To: "(dot)ep" <erick(dot)papa(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: LIKE conditions in PGSQL very, very slow!
Date: 2007-08-13 11:22:33
Message-ID: 46C03EF9.9060407@magproductions.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

.ep wrote:
> Hi,
>
> I'm moving from the mysql camp and quite liking things like functions
> and such, but a lot of my functionality depends on queries such as
>
> SELECT id, name, start_date
> FROM customer
> WHERE name LIKE 'eri%';
>
> These kinds of queries are super fast in MySQL because "eri%" type
> conditions also use the index. Is this not the case with PG?
>
> Here's the EXPLAIN output:
>
>
> CUSTDB=# explain select id,name,start_date from customer where name
> like 'eri%';
> QUERY PLAN
> ----------------------------------------------------------------
> Seq Scan on customer (cost=0.00..86032.18 rows=1 width=111)
> Filter: ((name)::text ~~ 'eri%'::text)
> (2 rows)

I think there's either no index on customer.name or you didn't analyze
the table, so PG has outdated statistics on its contents (probably
stating the table is still empty) and thinks a sequential scan will be
faster. You probably want to become acquainted with autovacuum.

Another possibility is that most of your customers names start with
'eri', in which case a seq scan is actually faster... In that case you
should probably do something about your customer base ;)

Regards,

--
Alban Hertroys
alban(at)magproductions(dot)nl

magproductions b.v.

T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede

// Integrate Your World //

In response to

Browse pgsql-general by date

  From Date Subject
Next Message hubert depesz lubaczewski 2007-08-13 11:23:16 Re: UDFs
Previous Message John Coulthard 2007-08-13 11:14:04 Re: Unable to connect to PostgreSQL server via PHP