Re: [PATCH] Erase the distinctClause if the result is unique by definition - Mailing list pgsql-hackers

From Andy Fan
Subject Re: [PATCH] Erase the distinctClause if the result is unique by definition
Date
Msg-id CAKU4AWrHSOGQ0q1wqnGk=kN8o4ZA=9uOyzL0eqY93=VkU4y08A@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Erase the distinctClause if the result is unique bydefinition  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: [PATCH] Erase the distinctClause if the result is unique bydefinition
List 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?   
Attachment

pgsql-hackers by date:

Previous
From: Ivan Taranov
Date:
Subject: custom postgres launcher for tests
Next
From: Julien Rouhaud
Date:
Subject: Re: [PATCH] Erase the distinctClause if the result is unique bydefinition