Re: grep -f keyword data query
| От | David Rowley |
|---|---|
| Тема | Re: grep -f keyword data query |
| Дата | |
| Msg-id | CAKJS1f-tAZ9X0_kdDtgPj6YF4AhUFE8V+W9XyVRzX1Vv3HhwSw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: grep -f keyword data query (Hiroyuki Sato <hiroysato@gmail.com>) |
| Ответы |
Re: grep -f keyword data query
|
| Список | pgsql-general |
On 30 December 2015 at 04:21, Hiroyuki Sato <hiroysato@gmail.com> wrote:
-- 2015年12月29日(火) 4:35 Jeff Janes <jeff.janes@gmail.com>:
But, the planner refuses to use this index for your query anyway,
because it can't see that the patterns are all left-anchored.
Really, your best bet is refactor your url data so it is stored with a
url_prefix and url_suffix column. Then you can do exact matching
rather than pattern matching.I see, exact matching faster than pattern matting.But I need pattern match in path part(ie, http://www.yahoo.com/a/b/c/... )I would like to pattern match '/a/b/c' part.
If your pattern matching is as simple as that, then why not split the /a/b/c/ part out as mentioned by Jeff? Alternatively you could just write a function which splits that out for you and returns it, then index that function, and then just include a call to that function in the join condition matching with the equality operator. That'll allow hash and merge joins to be possible again.
В списке pgsql-general по дате отправления: