| From: | James Mansion <james(at)mansionfamily(dot)plus(dot)com> |
|---|---|
| To: | mark(at)mark(dot)mielke(dot)cc |
| Cc: | Mark Lewis <mark(dot)lewis(at)mir3(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-06-06 22:23:13 |
| Message-ID: | 466733D1.1040308@mansionfamily.plus.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
mark(at)mark(dot)mielke(dot)cc wrote:
> What is a real life example where an intelligent and researched
> database application would issue a like or ilike query as their
> primary condition in a situation where they expected very high
> selectivity?
>
In my case the canonical example is to search against textual keys where
the search is
performed automatically if the user hs typed enough data and paused. In
almost all
cases the '%' trails, and I'm looking for 'starts with' in effect.
usually the search will have
a specified upper number of returned rows, if that's an available
facility. I realise in this
case that matching against the index does not allow the match count
unless we check
MVCC as we go, but I don't see why another thread can't be doing that.
James
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kurt Overberg | 2007-06-06 23:27:27 | Weird 8.2.4 performance |
| Previous Message | Dan Harris | 2007-06-06 22:04:44 | reclaiming disk space after major updates |