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
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
try JOINs...
Kenneth Marshall wrote:
EXISTS matches NULLs too and since they are not indexed a
sequential scan is needed to check for them. Try using
IN instead.
This is nonsense in more than one way.
regards
Yeb Havinga
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To
Yeb Havinga wrote:
Kenneth Marshall wrote:
EXISTS matches NULLs too and since they are not indexed a
sequential scan is needed to check for them. Try using
IN instead.
This is nonsense in more than one way.
Hit ctrl-return a bit too slow - exists does not match null but a set of
records,
Yeb Havinga a écrit :
Yeb Havinga wrote:
Kenneth Marshall wrote:
EXISTS matches NULLs too and since they are not indexed a
sequential scan is needed to check for them. Try using
IN instead.
This is nonsense in more than one way.
Hit ctrl-return a bit too slow - exists does not match null
Benoit Delbosc bdelb...@nuxeo.com writes:
I am trying to understand why inside an EXISTS clause the query planner
does not use the index:
I'm not sure this plan is as bad as all that. The key point is that the
planner is expecting 52517 rows that match that users_md5 value (and the
true
Tom Lane a écrit :
Benoit Delbosc bdelb...@nuxeo.com writes:
I am trying to understand why inside an EXISTS clause the query planner
does not use the index:
I'm not sure this plan is as bad as all that. The key point is that the
planner is expecting 52517 rows that match that users_md5
