Re: [bulk] Re: [bulk] Re: Problem with LIKE-Performance

From: "Tarabas (Manuel Rorarius)" <tarabas(at)tarabas(dot)de>
To: Richard Huxton <dev(at)archonet(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [bulk] Re: [bulk] Re: Problem with LIKE-Performance
Date: 2006-04-18 16:39:42
Message-ID: 779212585.20060418183942@tarabas.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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 time went down to 0.203 ms after I
changed the index to varchar_pattern_ops.

Index Scan using idx_image_title on image (cost=0.00..6.01 rows=1 width=1311) (actual time=0.027..0.108 rows=33 loops=1)
Index Cond: (((title)::text ~>=~ 'Davorka'::character varying) AND ((title)::text ~<~ 'Davorkb'::character varying))
Filter: ((title)::text ~~ 'Davorka%'::text)
Total runtime: 0.203 ms

Although 13 sec. for the first select seems a bit odd, I think after
the Database-Cache on the Table kicks in, it should be fine with ~500 ms

Best regards
Manuel

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message PFC 2006-04-18 17:00:40 Re: SELECT FOR UPDATE performance is bad
Previous Message Richard Huxton 2006-04-18 16:25:43 Re: [bulk] Re: Problem with LIKE-Performance