Re: Redundant Unique plan node for table with a unique index - Mailing list pgsql-hackers

From David Rowley
Subject Re: Redundant Unique plan node for table with a unique index
Date
Msg-id CAApHDvpD7fFk5O3aaACiZ+kNDaXs0+CP-9B8Ri7ZoFwXq4P_xA@mail.gmail.com
Whole thread Raw
In response to Redundant Unique plan node for table with a unique index  (Damir Belyalov <dam.bel07@gmail.com>)
Responses Re: Redundant Unique plan node for table with a unique index
List pgsql-hackers
On Thu, 14 Sept 2023 at 02:28, Damir Belyalov <dam.bel07@gmail.com> wrote:
> create table a (n int);
> insert into a (n) select x from generate_series(1, 140000) as g(x);
> create unique index on a (n);
> explain select distinct n from a;
>                                      QUERY PLAN
> ------------------------------------------------------------------------------------
>  Unique  (cost=0.42..6478.42 rows=140000 width=4)
>    ->  Index Only Scan using a_n_idx on a  (cost=0.42..6128.42 rows=140000 width=4)
> (2 rows)
>
>
> We can see that Unique node is redundant for this case. So I implemented a simple patch that removes Unique node from
theplan.
 

I don't think this is a good way to do this.  The method you're using
only supports this optimisation when querying a table directly.  If
there were subqueries, joins, etc then it wouldn't work as there are
no unique indexes.  You should probably have a look at [1] to see
further details of an alternative method without the said limitations.

David

[1] https://postgr.es/m/flat/CAKU4AWqZvSyxroHkbpiHSCEAY2C41dG7VWs%3Dc188KKznSK_2Zg%40mail.gmail.com



pgsql-hackers by date:

Previous
From: "Imseih (AWS), Sami"
Date:
Subject: Re: Jumble the CALL command in pg_stat_statements
Next
From: David Rowley
Date:
Subject: Re: Surely this code in setrefs.c is wrong?