Re: [PATCH] Erase the distinctClause if the result is unique by definition
От | Tom Lane |
---|---|
Тема | Re: [PATCH] Erase the distinctClause if the result is unique by definition |
Дата | |
Msg-id | 4952.1581355652@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] Erase the distinctClause if the result is unique by definition (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Ответы |
Re: [PATCH] Erase the distinctClause if the result is unique by definition
|
Список | pgsql-hackers |
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes: >> On Sat, Feb 8, 2020 at 12:53 PM Andy Fan <zhihui.fan1213@gmail.com> wrote: >> Do you mean adding some information into PlannerInfo, and when we create >> a node for Unique/HashAggregate/Group, we can just create a dummy node? > Not so much as PlannerInfo but something on lines of PathKey. See PathKey > structure and related code. What I envision is PathKey class is also > annotated with the information whether that PathKey implies uniqueness. > E.g. a PathKey derived from a Primary index would imply uniqueness also. A > PathKey derived from say Group operation also implies uniqueness. Then just > by looking at the underlying Path we would be able to say whether we need > Group/Unique node on top of it or not. I think that would make it much > wider usecase and a very useful optimization. FWIW, that doesn't seem like a very prudent approach to me, because it confuses sorted-ness with unique-ness. PathKeys are about sorting, but it's possible to have uniqueness guarantees without having sorted anything, for instance via hashed grouping. I haven't looked at this patch, but I'd expect it to use infrastructure related to query_is_distinct_for(), and that doesn't deal in PathKeys. regards, tom lane
В списке pgsql-hackers по дате отправления: