| From: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Damir Belyalov <dam(dot)bel07(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, a(dot)lepikhov(at)postgrespro(dot)ru |
| Subject: | Re: Redundant Unique plan node for table with a unique index |
| Date: | 2023-09-14 01:17:58 |
| Message-ID: | CAKU4AWp60USTODSvve3-iQJ5um=SQLXJ95AvmdO9A6+qcS9LTA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
>
> 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
>
>
The nullable tracking blocker probably has been removed by varnullingrels
so I will start working on UniqueKey stuff very soon, thank you David
for remember of this feature!
--
Best Regards
Andy Fan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-09-14 01:32:02 | Re: Avoid a possible null pointer (src/backend/utils/adt/pg_locale.c) |
| Previous Message | Tom Lane | 2023-09-14 00:01:39 | Re: Inefficiency in parallel pg_restore with many tables |