Re: SELECT DISTINCT scans the table? - Mailing list pgsql-general

From Tom Lane
Subject Re: SELECT DISTINCT scans the table?
Date
Msg-id 1238959.1639687677@sss.pgh.pa.us
Whole thread Raw
In response to SELECT DISTINCT scans the table?  (Markus Demleitner <msdemlei@ari.uni-heidelberg.de>)
Responses Re: SELECT DISTINCT scans the table?  (Markus Demleitner <msdemlei@ari.uni-heidelberg.de>)
List pgsql-general
Markus Demleitner <msdemlei@ari.uni-heidelberg.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



pgsql-general by date:

Previous
From: Bryn Llewellyn
Date:
Subject: Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL
Next
From: Adrian Klaver
Date:
Subject: Re: Packages, inner subprograms, and parameterizable anonymous blocks for PL/pgSQL