| From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
|---|---|
| To: | mark(at)mark(dot)mielke(dot)cc |
| Cc: | Richard Huxton <dev(at)archonet(dot)com>, 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:06:46 |
| Message-ID: | 465717A6.4040503@commandprompt.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
mark(at)mark(dot)mielke(dot)cc wrote:
> I am speaking of contains, as contains is the one that was said to
> require a seqscan. I am questioning why it requires a seqscan. The
> claim was made that with MVCC, the index is insufficient to check
> for visibility and that the table would need to be accessed anyways,
> therefore a seqscan is required. I question whether a like '%bar%'
> should be considered a high selectivity query in the general case.
> I question whether a worst case should be assumed.
If you are doing %bar% you should be using pg_tgrm or tsearch2.
J
>
> Perhaps I question too much? :-)
>
> Cheers,
> mark
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Huxton | 2007-05-25 17:08:53 | Re: LIKE search and performance |
| Previous Message | mark | 2007-05-25 16:56:33 | Re: LIKE search and performance |