Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 3D1DE9F9386 for ; Wed, 29 Aug 2007 14:12:43 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 86428-08 for ; Wed, 29 Aug 2007 14:12:35 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mir3-fs.mir3.com (mail.mir3.com [65.208.188.100]) by postgresql.org (Postfix) with ESMTP id 2A4499F9582 for ; Wed, 29 Aug 2007 14:12:35 -0300 (ADT) Received: MIR3-FS.mir3.com 172.16.1.11 from 172.16.2.68 172.16.2.68 via HTTP with MS-WebStorage 6.0.6249 Received: from archimedes by MIR3-FS.mir3.com; 29 Aug 2007 10:12:31 -0700 Subject: Re: LIKE query verses = From: Mark Lewis To: Karthikeyan Mahadevan Cc: pgsql-performance@postgresql.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: MIR3, Inc. Date: Wed, 29 Aug 2007 10:12:31 -0700 Message-Id: <1188407551.22730.113.camel@archimedes> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200708/380 X-Sequence-Number: 26510 On Wed, 2007-08-29 at 18:01 +0530, Karthikeyan Mahadevan wrote: > > ************************************************************************************************************************* > 1) > > EXPLAIN ANALYSE SELECT > job_category.job_id,job.name,job.state,job.build_id,cat.name as > reporting_group > FROM category,job_category,job,category as cat > WHERE job.job_id=job_category.job_id > AND job_category.category_id=category.category_id > AND cat.build_id=category.build_id > AND category.name = 'build_id.pap3260-20070828_01' > AND cat.name like ('reporting_group.Tier2%'); > > QUERY PLAN > ------------------------------------------------------------------------------------------------------------------------------------------------------ > Nested Loop (cost=0.00..291.53 rows=8 width=103) (actual > time=98.999..385.590 rows=100 loops=1) > -> Nested Loop (cost=0.00..250.12 rows=9 width=34) (actual > time=98.854..381.106 rows=100 loops=1) > -> Nested Loop (cost=0.00..123.22 rows=1 width=34) (actual > time=98.717..380.185 rows=1 loops=1) > -> Index Scan using idx_cat_by_name on category cat > (cost=0.00..5.97 rows=1 width=34) (actual time=95.834..245.276 > rows=977 loops=1) > Index Cond: (((name)::text >= > 'reporting'::character varying) AND ((name)::text < > 'reportinh'::character varying)) > Filter: ((name)::text ~~ > 'reporting_group.Tier2%'::text) > -> Index Scan using idx_cat_by_bld_id on category > (cost=0.00..117.24 rows=1 width=8) (actual time=0.134..0.134 rows=0 > loops=977) > Index Cond: ("outer".build_id = > category.build_id) > Filter: ((name)::text = > 'build_id.pap3260-20070828_01'::text) > -> Index Scan using idx_jcat_by_cat_id on job_category > (cost=0.00..126.00 rows=71 width=8) (actual time=0.126..0.569 > rows=100 loops=1) > Index Cond: (job_category.category_id = > "outer".category_id) > -> Index Scan using job_pkey on job (cost=0.00..4.59 rows=1 > width=73) (actual time=0.033..0.036 rows=1 loops=100) > Index Cond: (job.job_id = "outer".job_id) > > Total runtime: 385.882 ms > ------------------------------------------------------------------------------------------------------------------------------------------------------ Remember that using LIKE causes PG to interpret an underscore as 'any character', which means that it can only scan the index for all records that start with 'reporting', and then it needs to apply a filter to each match. This is going to be slower than just going directly to the matching index entry. What you probably want to do is tell PG that you're looking for a literal underscore and not for any matching character by escaping the underscore, that will allow it to do a much quicker index scan. Something like: cat.name like 'reporting|_group.Tier2%' ESCAPE '|' -- Mark Lewis