Re: MERGE command for inheritance

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: MERGE command for inheritance
Дата
Msg-id 4C627A89.60108@enterprisedb.com
обсуждение исходный текст
Ответ на Re: MERGE command for inheritance  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: MERGE command for inheritance  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On 11/08/10 11:45, Simon Riggs wrote:
> On Tue, 2010-08-10 at 17:15 +0300, Heikki Linnakangas wrote:
>> On 10/08/10 12:38, Boxuan Zhai wrote:
>>> The difficult way is to generate the plans for children table in planner, as
>>> the other commands like UPDATE and DELETE. However, because the structure of
>>> MERGE plan is much more complex than the ordinary ModifyTable plans, this
>>> job may not as simple as we expected. We need to adjust both the main plan
>>> and the
>>> merge actions to fit the children tables, which is not straight forward.
>>
>> This the approach you'll have to take. But actually, I'm surprised it
>> doesn't happen to just work already. It should be opaque to the merge
>> facility that the reference to the parent target table has inherited
>> child tables - expanding the inherited table to scans of all the
>> children should already be handled by the planner.
>
> The support for UPDATE and SELECT of partitioned cases is very different
> in the planner and was handled as separate implementation projects.

Ok, thinking and experminting this some more I finally understand what 
the problem is. Yeah, the patch doesn't currently work when the target 
table has inherited child tables, it only takes the parent table into 
account and ignores all child tables.

> If we want a working MERGE in the next release, I suggest that we break
> down this project in the same way and look at partitioned target tables
> as a separate project.
>
> One reason for suggesting this is that all MERGE statements have a
> source table, whereas UPDATE and DELETEs did not always. The plan for a
> simple UPDATE and DELETE against a partitioned table is simple, but the
> plan (and performance) of a joined UPDATE or DELETE is not good:

I don't think we can just leave it as it is. If the performance sucks, 
that's fine and can be handled in a future release, but it should at 
least produce the correct result.

I concur that Boxuan's suggested "difficult" approach seems like the 
right one.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Marko Tiikkaja
Дата:
Сообщение: Re: assertions and constraint triggers
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Bug / shortcoming in has_*_privilege