From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Subject: | Re: MERGE SQL statement for PG12 |
Date: | 2019-01-15 19:14:53 |
Message-ID: | 20190115191453.qkh5kyt7zyzlwxli@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-01-15 14:05:25 -0500, Robert Haas wrote:
> On Mon, Jan 14, 2019 at 1:37 AM Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> wrote:
> > Can you please help me understand what's fundamentally wrong with
> > the approach and more importantly, can you please explain what would
> > the the architecturally sound way to do this? The same also applies
> > to the executor side where the current approach is deemed wrong, but
> > very little is said on what's the correct way.
>
> [ Long and good explanation by Robert ]
> I want to point out that it is not as if nobody has reviewed this
> patch previously. Here is Andres making basically the same point
> about parse analysis that I'm making here -- FWIW, I didn't find his
> reply until after I'd written the above:
>
> https://www.postgresql.org/message-id/20180403021800.b5nsgiclzanobiup%40alap3.anarazel.de
>
> Here he is explaining these points some more:
>
> https://www.postgresql.org/message-id/20180405200003.gar3j26gsk32gqpe%40alap3.anarazel.de
>
> And here's Peter Geoghegan not only explaining the same problem but
> having a go at fixing it:
>
> https://www.postgresql.org/message-id/CAH2-Wz%3DZwNQvp11XjeHo-dBLHr9GDRi1vao8w1j7LQ8mOsUkzw%40mail.gmail.com
>
> Actually, I see that Peter Geoghegan not just the emails above but a
> blizzard of other emails explaining the structural problems with the
> patch, which I now see include not only the parse analysis concerns
> but also the business of multiple RTEs which I mentioned above.
+ many.
Pavan, I think the reason you're not getting much further feedback is
that you and Simon have gotten a lot and only incorporated feedback only
very grudgingly, if at all. You've not even attempted to sketch out a
move of the main merge handling from parse-analysis to planner, as far
as I can tell, despite this being one of the main criticisms for about a
year. Given that not much besides rebasing has happened since v11, I
don't find it surprising that people don't want to invest more energy in
this patch.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-01-15 19:39:38 | Re: Ryu floating point output patch |
Previous Message | Robert Haas | 2019-01-15 19:05:25 | Re: MERGE SQL statement for PG12 |