Re: SELECT DISTINCT <constant> scans the table?

Markus Demleitner <msdemlei(at)ari(dot)uni-heidelberg(dot)de> writes:
> Maximally stripped down, my problem is that

> select distinct 300 from <bigtable>

> seqscans <bigtable> (at least in PostgreSQL 11.14). To me, it seems
> obvious that this ought be be just one row containing 300 once
> Postgres has established that <bigtable> is nonempty.

> Why do things not work like this? Am I missing something major?

That seems like the sort of optimization that we absolutely should
not spend cycles looking for. If it were a trivial change consuming
no detectable number of planning cycles, maybe it would be worth the
development and maintenance effort; though I'd be dubious about the
value. But the fact that it'd have to be transformed into something
testing whether the table is nonempty makes it fairly nontrivial.
I doubt it's worth the development cost plus the cycles imposed
on every other query.

regards, tom lane