Re: Redundant Unique plan node for table with a unique index

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Redundant Unique plan node for table with a unique index
Дата
Msg-id CAApHDvpD7fFk5O3aaACiZ+kNDaXs0+CP-9B8Ri7ZoFwXq4P_xA@mail.gmail.com
обсуждение исходный текст
Ответ на Redundant Unique plan node for table with a unique index  (Damir Belyalov <dam.bel07@gmail.com>)
Ответы Re: Redundant Unique plan node for table with a unique index  (Andy Fan <zhihui.fan1213@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Imseih (AWS), Sami"
Дата:
Сообщение: Re: Jumble the CALL command in pg_stat_statements
Следующее
От: David Rowley
Дата:
Сообщение: Re: Surely this code in setrefs.c is wrong?