From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Gaetano Mendola <mendola(at)bigfoot(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Wrong plan sequential scan instead of an index one |
Date: | 2007-03-30 09:48:12 |
Message-ID: | 460CDCDC.7020901@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Gaetano Mendola wrote:
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>
> Hi all, take a look at those plans:
>
>
> test=# explain analyze SELECT COUNT(id) FROM t_oa_2_00_card WHERE
> pvcp in (select id from l_pvcp where value ilike '%pi%');
> -> Hash IN Join (cost=2.22..153835.49 rows=177404 width=8) (actual
> time=2.908..4001.814 rows=7801 loops=1) Hash Cond: ("outer".pvcp =
> "inner".id)
> Isn't too much choose a sequential scan due to 19 estimated rows when
> with 4 estimated does a correct index scan ?
I don't think it's the matches on l_pvcp that's the problem, it's the
fact that it thinks its getting 177404 rows matching the IN.
Now, why 19 rows from the subquery should produce such a large estimate
in the outer query I'm not sure. Any strange distribution of values on pvcp?
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Claus Guttesen | 2007-03-30 09:51:03 | Re: Wrong plan sequential scan instead of an index one |
Previous Message | Gaetano Mendola | 2007-03-30 09:32:49 | Wrong plan sequential scan instead of an index one |