| From: | Richard Huxton <dev(at)archonet(dot)com> |
|---|---|
| To: | PFC <lists(at)peufeu(dot)com> |
| Cc: | mark(at)mark(dot)mielke(dot)cc, Mark Lewis <mark(dot)lewis(at)mir3(dot)com>, James Mansion <james(at)mansionfamily(dot)plus(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Alexander Staubo <alex(at)purefiction(dot)net>, Andy <frum(at)ar-sd(dot)net>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: LIKE search and performance |
| Date: | 2007-05-25 17:32:39 |
| Message-ID: | 46571DB7.2040607@archonet.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
PFC wrote:
>> None of which address the question of what plan PG should produce for:
>> SELECT * FROM bigtable WHERE foo LIKE 's%'
>
> Ah, this one already uses the btree since the '%' is at the end.
> My point is that a search like this will yield too many results to
> be useful to the user anyway, so optimizing its performance is a kind of
> red herring.
At the *application level* yes.
At the *query planner* level no.
At the query planner level I just want it to come up with the best plan
it can. The original argument was that PG's estimate of the number of
matching rows was too optimistic (or pessimistic) in the case where we
are doing a contains substring-search.
--
Richard Huxton
Archonet Ltd
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2007-05-25 17:58:13 | Re: LIKE search and performance |
| Previous Message | PFC | 2007-05-25 17:31:16 | Re: LIKE search and performance |