Re: [HACKERS] MERGE SQL Statement for PG11

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: [HACKERS] MERGE SQL Statement for PG11
Дата
Msg-id CABOikdMXQbSWAMNZL9Xodai8Lc0YpqXo_8ABQTBzqbmijEbJ9g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] MERGE SQL Statement for PG11  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: [HACKERS] MERGE SQL Statement for PG11
Список pgsql-hackers


On Wed, Feb 7, 2018 at 10:52 PM, Peter Geoghegan <pg@bowt.ie> wrote:


Apparently there is a pending patch to do better there - the commit
message of 2f178441 refers to this.


Thanks. Will look at it.
 
> The revised version also supports subqueries in SET targetlist as well as
> WHEN AND conditions. As expected, this needed a minor tweak in
> query/expression mutators. So once I worked on that for partitioned tables,
> subqueries started working with very minimal adjustments elsewhere. Other
> things such as whole-var references are still broken. A few new tests are
> also added.

Great!

Wholerow references are expected to be a bit trickier. See commit
ad227837 for some hints on how you could fix this.

Thanks again.
 

> Next I am going to look at RLS. While I've no prior experience with RLS, I
> am expecting it to be less cumbersome in comparison to partitioning. I am
> out of action till Monday and may not be able to respond in time. But any
> reviews and comments are appreciated as always.

I don't think that RLS support will be particularly challenging. It
might take a while.

Ok. I would start from writing a test case to check what works and what doesn't with the current patch and work from there. My understanding of RLS is limited right now, but from what I've seen in the code (while hacking other stuff), my guess is it will require us evaluating a set of quals and then deciding on the action.
 

If your rapid progress here is any indication, most open items are not
likely to be particularly challenging. Once again, I suggest that a
good area for us to focus on is the semantics of READ COMMITTED
conflict handling.

I understand getting EPQ semantics right is very important. Can you please (once again) summarise your thoughts on what you think is the *most* appropriate behaviour? I can then think how much efforts might be involved in that. If the efforts are disproportionately high, we can discuss if settling for some not-so-nice semantics, like we apparently did for partition key updates.

I am sorry, I know you and Simon have probably done that a few times already and I should rather study those proposals first. So it's okay if you don't want to repeat those; I will work on them next week once I am back from holidays.

Maybe you'd prefer to just blast through the
simpler open items, which is fine, but do bear in mind that the EPQ
and EPQ-adjacent stuff is probably going to be the thing that makes or
breaks this patch for v11.

TBH I did not consider partitioning any less complex and it was indeed very complex, requiring at least 3 reworks by me. And from what I understood, it would have been a blocker too. So is subquery handling and RLS. That's why I focused on addressing those items while you and Simon were still debating EPQ semantics.

Thanks,
Pavan

--
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: SSL test names