Re: [PATCH] Erase the distinctClause if the result is unique by definition

Поиск
Список
Период
Сортировка
От Andy Fan
Тема Re: [PATCH] Erase the distinctClause if the result is unique by definition
Дата
Msg-id CAKU4AWrHSOGQ0q1wqnGk=kN8o4ZA=9uOyzL0eqY93=VkU4y08A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Erase the distinctClause if the result is unique bydefinition  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: [PATCH] Erase the distinctClause if the result is unique bydefinition  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers


On Tue, Feb 11, 2020 at 3:56 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
>
> and if we prepare sql outside a transaction, and execute it in the
> transaction, the other session can't drop the constraint until the
> transaction is ended.

And what if you create a view on top of a query containing a distinct clause
rather than using prepared statements?  FWIW your patch doesn't handle such
case at all, without even needing to drop constraints:

CREATE TABLE t (a int primary key, b int not null,  c int);
INSERT INTO t VALUEs(1, 1, 1), (2, 2, 2);
CREATE UNIQUE INDEX t_idx1 on t(b);
CREATE VIEW v1 AS SELECT DISTINCT b FROM t;
EXPLAIN SELECT * FROM v1;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.


This error can be fixed with

-       num_of_rtables = bms_num_members(non_semi_anti_relids);
+       num_of_rtables = list_length(query->rtable);

This test case also be added into the patch.   
 
I also think this is not the right way to handle this optimization.

do you have any other concerns?   
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ivan Taranov
Дата:
Сообщение: custom postgres launcher for tests
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: [PATCH] Erase the distinctClause if the result is unique bydefinition