Re: MERGE command for inheritance - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: MERGE command for inheritance
Date
Msg-id 4C627A89.60108@enterprisedb.com
Whole thread Raw
In response to Re: MERGE command for inheritance  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: MERGE command for inheritance
List 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 by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: assertions and constraint triggers
Next
From: Robert Haas
Date:
Subject: Re: Bug / shortcoming in has_*_privilege