From: | Kenneth Marshall <ktm(at)rice(dot)edu> |
---|---|
To: | Benoit Delbosc <bdelbosc(at)nuxeo(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Bad query plan inside EXISTS clause |
Date: | 2010-03-10 13:43:42 |
Message-ID: | 20100310134342.GA29320@it.is.rice.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
EXISTS matches NULLs too and since they are not indexed a
sequential scan is needed to check for them. Try using
IN instead.
Cheers,
Ken
On Wed, Mar 10, 2010 at 02:26:20PM +0100, Benoit Delbosc wrote:
> Hi all,
>
> I am trying to understand why inside an EXISTS clause the query planner
> does not use the index:
>
> EXPLAIN ANALYZE SELECT 1 WHERE EXISTS (SELECT 1 FROM read_acls_cache
> WHERE users_md5 = '9bc9012eb29c0bb2ae3cc7b5e78c2acf');
> QUERY PLAN
> --------------------------------------------------------------------------------------------
> Result (cost=1.19..1.20 rows=1 width=0) (actual time=466.317..466.318
> rows=1 loops=1)
> One-Time Filter: $0
> InitPlan 1 (returns $0)
> -> Seq Scan on read_acls_cache (cost=0.00..62637.01 rows=52517
> width=0) (actual time=466.309..466.309 rows=1 loops=1)
> Filter: ((users_md5)::text =
> '9bc9012eb29c0bb2ae3cc7b5e78c2acf'::text)
> Total runtime: 466.369 ms
> (6 rows)
>
> While it does use the index when executing only the subquery:
>
> EXPLAIN ANALYZE SELECT 1 FROM read_acls_cache WHERE users_md5 =
> '9bc9012eb29c0bb2ae3cc7b5e78c2acf';
> QUERY PLAN
> --------------------------------------------------------------------------
> Bitmap Heap Scan on read_acls_cache (cost=2176.10..35022.98 rows=52517
> width=0) (actual time=9.065..21.988 rows=51446 loops=1)
> Recheck Cond: ((users_md5)::text =
> '9bc9012eb29c0bb2ae3cc7b5e78c2acf'::text)
> -> Bitmap Index Scan on read_acls_cache_users_md5_idx
> (cost=0.00..2162.97 rows=52517 width=0) (actual time=8.900..8.900
> rows=51446 loops=1)
> Index Cond: ((users_md5)::text =
> '9bc9012eb29c0bb2ae3cc7b5e78c2acf'::text)
> Total runtime: 25.464 ms
> (5 rows)
>
> The table has been vacuumed, analyzed and reindexed.
>
> Thanks for your support.
>
> Regards
>
> ben
>
> Here are some more info :
>
> \d read_acls_cache
> Table "public.read_acls_cache"
> Column | Type | Modifiers
> -----------+-----------------------+-----------
> users_md5 | character varying(34) | not null
> acl_id | character varying(34) |
> Indexes:
> "read_acls_cache_users_md5_idx" btree (users_md5)
>
>
> SELECT COUNT(*) FROM read_acls_cache;
> count
> ---------
> 2520899
> (1 row)
>
>
> SELECT COUNT(DISTINCT(users_md5)) FROM read_acls_cache ;
> count
> -------
> 49
> (1 row)
>
>
> SELECT Version();
> version
> ------------------------------------------------------------------
> PostgreSQL 8.4.2 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.2.real
> (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4), 64
> (1 row)
>
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
From | Date | Subject | |
---|---|---|---|
Next Message | Yeb Havinga | 2010-03-10 13:51:04 | Re: Bad query plan inside EXISTS clause |
Previous Message | Grzegorz Jaśkiewicz | 2010-03-10 13:43:41 | Re: Bad query plan inside EXISTS clause |