On Tue, 26 Jul 2005, Joseph Shraibman wrote:
> Stephan Szabo wrote:
>
> > It is for the operators ~<~, ~<=~, ~=~, ~>=~, ~>~ (for like optimization).
> > The docs seem to say that it does a character by character comparison
> > rather than one using the collation thus being better for pattern
> > m
Stephan Szabo wrote:
It is for the operators ~<~, ~<=~, ~=~, ~>=~, ~>~ (for like optimization).
The docs seem to say that it does a character by character comparison
rather than one using the collation thus being better for pattern
matching. I'd think letting it do <, <=, =, >=, > would have i
On Tue, 26 Jul 2005, Joseph Shraibman wrote:
>
>
> Stephan Szabo wrote:
> > On Tue, 26 Jul 2005, Joseph Shraibman wrote:
> >
> >
> >>I have this index:
> >>
> >>"directory_lower_username_seg_key" unique, btree (lower(username)
> >>text_pattern_ops, seg)
> >>
> >>... but my query refuses to use tha
On Tue, 26 Jul 2005, Joseph Shraibman wrote:
> I have this index:
>
> "directory_lower_username_seg_key" unique, btree (lower(username)
> text_pattern_ops, seg)
>
> ... but my query refuses to use that index.
text_pattern_ops is an opclass for doing LIKE queries using the index, I
don't believe i
Stephan Szabo wrote:
On Tue, 26 Jul 2005, Joseph Shraibman wrote:
I have this index:
"directory_lower_username_seg_key" unique, btree (lower(username)
text_pattern_ops, seg)
... but my query refuses to use that index.
text_pattern_ops is an opclass for doing LIKE queries using the index
Madison Kelly wrote:
Joseph Shraibman wrote:
What happens if you 'SET enable_seqscan TO OFF' and try the query
again? I've had a couple of instances where the planner just doesn't
like my index but once it is told to use it I get a nice performance boost.
It still does a seqscan.
-
Joseph Shraibman wrote:
I have this index:
"directory_lower_username_seg_key" unique, btree (lower(username)
text_pattern_ops, seg)
... but my query refuses to use that index.
[local]:owl=>explain select * from directory where lower(username) =
'jks@selectacast.net';
