Hi Richard,
RH> As you can see, the plan is still scanning all the rows. In any case,
RH> you've changed the query - this has % at the beginning and end, which no
RH> index will help you with.
I realize that, the index definately helped a lot with the query where
the % is just at the end. The ti
Hi Tom,
TL> As already noted, it might be worth your while to add an index using the
TL> pattern-ops opclass to help with queries like this.
I have done that now and it works very fine as supposed.
The problem with the high startup_costs disappeared somehow after the
change of the enable_seqscan
Hi Hakan,
HK> i remember something that you need a special index with locales<>"C".
HK> You nned a different operator class for this index smth. like:
HK> CREATE INDEX idx_image_title
HK> ON image
HK> USING btree
HK> (title varchar_pattern_ops);
I also forgot that, thanks a lot for the hint
Hi Tom,
TL> "Tarabas (Manuel Rorarius)" <[EMAIL PROTECTED]> writes:
>> I get the following explain and I am troubled by the very high
>> "startup_cost" ... does anyone have any idea why that value is so
>> high?
>> {SEQSCAN
>>:startu
Hi Dave,
DD> It looks like you are getting a sequential scan instead of an index
DD> scan. What is your locale setting? As far as I know Postgres doesn't
DD> support using indexes with LIKE unless you are using the C locale.
Actually no, I am using de_DE as locale because I need the german
orde
Hi!
I am having trouble with like statements on one of my tables.
I already tried a vacuum and analyze but with no success.
The database is PostgreSQL Database Server 8.1.3 on i686-pc-mingw32
I get the following explain and I am troubled by the very high
"startup_cost" ... does anyone hav
