Skip site navigation (1) Skip section navigation (2)

merge command - GSoC progress

From: Boxuan Zhai <bxzhai2010(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: merge command - GSoC progress
Date: 2010-07-27 05:04:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
---------- Forwarded message ----------
From: Boxuan Zhai <bxzhai2010(at)gmail(dot)com>
Date: 2010/7/26
Subject: Re: GSoC progress
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>


I have get a edition that the merge command can run. It accept the standard
merge command and can do UPDATE, INSERT and DELETE actions now. But we
cannot put additional qualification for actions. There are some bugs when we
try to evaluate the quals which make the system quit. I will fix it soon.

The merge actions are packed in ModifyTable nodes now. This can benefit the
coding if we want to implement MERGE ... RETURNING ...

Please find the patch file in attachment.

2010/7/24 Robert Haas <robertmhaas(at)gmail(dot)com>

 On Fri, Jul 23, 2010 at 12:21 PM, Boxuan Zhai <bxzhai2010(at)gmail(dot)com> wrote:
> > I my current implementation, the overall merge command plan is still a
> > single ModifyTable node. And the main query of merge command is in the
> field
> > of ModifyTable.plans. I add a new "List * mergeActPstates" field in the
> > structure of ModifyTableState. When apply the ExecInitModifyTable()
> function
> > on a ModifyTable node of a merge command, the function will do an extra
> work
> > to init all the merge actions and put the result into the
> > list of  mergeActPstates. (in previous design, I put the list in
> > PlannedStmt, but that makes the code a little bit ugly).
> Hmm, that might work.
> > I now put all merge-command-related functions in the file of
> > nodeModifyTable.c. and I have fixed something that I missed in the init
> > process for merge command, such as set the junkfiler attribute for ctid.
> > However, I still cannot run ExecProject over the tuple slot returned
> by main
> > query.
> >
> > In fact, I am not sure how  ExecProject () works exactly. It totally
> depends
> > on the correctness of the input ProjectionInfo, in which we have a
> > "ExprContext *pi_exprContext" parameter. The expression context should
> > contains all the tuple slot needed for the projection. I
> > init  ProjectionInfo correctly, but the expression context is empty when
> > initialized. Could you tell me WHEN does the system fill the tuple slots
> > (the ecxt_scantuple, ecxt_innertuple, ecxt_outertuple) in the expression
> > context of the ProjectionInfo structure?
> I'm not real familiar with this part of the code; that would be a good
> question to ask on pgsql-hackers.  But I believe the answer is that
> the individual node types initialize the expression context at the
> appropriate time.  For example, if you grep for ecxt_innertuple,
> you'll find that it's set in the hash, merge, and nestloop nodes;
> whereas the scan tuple is set by the scan, bitmap heap, and index scan
> nodes.
> --
>  Robert Haas
> EnterpriseDB:
> The Enterprise Postgres Company

Attachment: merge_run_no_qual.patch
Description: text/plain (61.5 KB)


pgsql-hackers by date

Next:From: Fujii MasaoDate: 2010-07-27 05:28:29
Subject: Re: Synchronous replication
Previous:From: Fujii MasaoDate: 2010-07-27 04:43:35
Subject: Re: Synchronous replication

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group