diff --git a/django/db/models/sql/where.py b/django/db/models/sql/where.py
index 43ac42489a..a711103485 100644
--- a/django/db/models/sql/where.py
+++ b/django/db/models/sql/where.py
@@ -50,7 +50,7 @@ class WhereNode(tree.Node):
         if hasattr(obj, "process"):
             try:
                 obj, params = obj.process(lookup_type, value)
-            except EmptyShortCircuit:
+            except (EmptyShortCircuit, EmptyResultSet):
                 # There are situations where we want to short-circuit any
                 # comparisons and make sure that nothing is returned. One
                 # example is when checking for a NULL pk value, or the
diff --git a/tests/regressiontests/queries/models.py b/tests/regressiontests/queries/models.py
index 6d0ee8c9a9..727a537e43 100644
--- a/tests/regressiontests/queries/models.py
+++ b/tests/regressiontests/queries/models.py
@@ -1048,11 +1048,14 @@ performance problems on backends like MySQL.
 [<Annotation: a1>]
 
 Nested queries should not evaluate the inner query as part of constructing the
-SQL. This test verifies this: if the inner query is evaluated, the outer "in"
-lookup will raise an EmptyResultSet exception (as the inner query returns
-nothing).
->>> print Annotation.objects.filter(notes__in=Note.objects.filter(note="xyzzy")).query
-SELECT ...
+SQL (so we should see a nested query here, indicated by two "SELECT" calls).
+>>> Annotation.objects.filter(notes__in=Note.objects.filter(note="xyzzy")).query.as_sql()[0].count('SELECT')
+2
+
+Bug #10181 -- Avoid raising an EmptyResultSet if an inner query is provably
+empty (and hence, not executed).
+>>> Tag.objects.filter(id__in=Tag.objects.filter(id__in=[]))
+[]
 
 Bug #9997 -- If a ValuesList or Values queryset is passed as an inner query, we
 make sure it's only requesting a single value and use that as the thing to