Does writing SELECT 1 instead of SELECT * inside an EXISTS subquery make it faster?

## What EXISTS asks for `EXISTS (subquery)` is a predicate, not a value expression. It evaluates to true when the subquery would produce at least one row and false when it would produce none. It never inspects the contents of that row — there is no operation defined on the subquery's output other than "is it empty". Consequently the subquery's select list carries no information into the enclosing query. ```sql -- these three are the same question SELECT c.id FROM customers c WHERE EXISTS (SELECT * FROM orders o WHERE o.customer_id = c.id); SELECT c.id FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id); SELECT c.id FROM customers c WHERE EXISTS (SELECT NULL FROM orders o WHERE o.customer_id = c.id); ``` PostgreSQL's and MySQL's manuals both state explicitly that what appears in the `SELECT` list of an `EXISTS` subquery does not matter. The plans are the same; the results are the same. The engine stops as soon as existence is decided, and it was never going to materialise those columns in the first place. ## Why the myth is so persistent Two reasons. First, the general advice "never write `SELECT *`" is taught as an unconditional rule, and people apply rules where they were never needed. Second, it feels like it *ought* to matter — the star means "all columns" everywhere else, so it looks like a request for work. The mistake is treating the subquery as if it produced a result set the outer query consumes; it does not, it produces a truth value. This is a good calibration question in an interview. Someone who says "always use `SELECT 1`, it's faster" is repeating folklore. Someone who says "it makes no difference; the list is ignored, though I write `1` because it signals intent" understands both the semantics and why the convention exists anyway. ## The one way the list still matters The select list must still be a legal, resolvable expression list. This errors, even though no value is ever needed: ```sql -- error: no such column, caught at resolution time SELECT c.id FROM customers c WHERE EXISTS (SELECT o.no_such_column FROM orders o WHERE o.customer_id = c.id); ``` So the subquery is not exempt from name resolution — only from evaluation. That distinction is worth stating explicitly, because it is the precise boundary between "ignored" and "absent". A second, smaller practical note: `SELECT *` inside `EXISTS` is convenient because it never has to be maintained. There is no column name in it to become wrong when the table changes, which is exactly the opposite of the situation in a stored view or an `INSERT ... SELECT`. ## What actually determines the cost Since the projection is free, everything that decides whether an `EXISTS` subquery is cheap or expensive lives elsewhere: the correlation predicate, whether an index serves it, and how many outer rows the predicate is evaluated for. If an `EXISTS` is slow, the projection is the last place to look — and "I changed `*` to `1` and it got faster" is almost always a measurement artefact such as a warm cache or a re-planned statement. ## Style, stated honestly Many teams standardise on `SELECT 1` purely for readability: it signals to a human reader that no columns are wanted and pre-empts the reviewer who would otherwise flag the star out of habit. That is a fine reason. It is just not a performance reason, and presenting it as one is the error the question is probing for.