Prev: Reworks of DML permission checks
Next: pgsql: Add support for TCPkeepalives on Windows, both for backend and
From: Heikki Linnakangas on 16 Jul 2010 02:13
On 16/07/10 03:26, Boxuan Zhai wrote:
> PS: Heikki asked me about what the "EXPLAIN MERGE ..." command will do.
> Well, I have not test it, but it may through an error or just explain the
> top plan, since I put the action plans in a new field, which cannot be
> recognized by old functions.

I meant what EXPLAIN MERGE output will look like after the project is
finished, not what it will do at this stage. I was trying to get a
picture of how you're thinking to implement the executor, what nodes
there is in a MERGE plan.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Simon Riggs on 17 Jul 2010 06:17
On Fri, 2010-07-16 at 08:26 +0800, Boxuan Zhai wrote:
> The merge actions are transformed into lower level queries. I create a
> Query node for each of them and append them in a newly create List
> field mergeActQry. The action queries have different command type and
> specific target list and qual list, according to their declaration by
> user. But they all share the same range table. This is because we
> don't need the action queries to be planned latter. The joining
> strategy is decided by the top query. We are only interest in their
> specific action qualifications. In other words, these action queries
> are only containers for their target list and qualifications.
>
> 2. When the query is ready, it will be send to rewriter. In this part,
> we can call RewriteQuery() to handle the action queries. The UPDATE
> action will trigger rules on UPDATE, and so on. What need to be
> noticed are: 1. the actions of the same type should not be rewritten
> repeatedly. If there are two UPDATE actions in merge command, we
> should not trigger the ON UPDATE rules twice. 2. if an action type is
> fully replaced by rules, we should remove all actions of this type
> from the action list.
> Rewriter will also do some process on the target list of each action.

IMHO it is a bad thing that we are attempting to execute each action
statement as a query. That means we need to execute an inner SQL
statement for each row returned by the top level query.

That design makes MERGE similar in performance to an upsert PL/pgsql
function, which will perform terribly on large numbers of rows.

This was exactly the point where I stopped implementation previously:
attempting to make MERGE work with rules is enough to prevent a tighter
in-executor implementation of the action list.

[To Boxuan, on a personal note, you seem to be coping quite well with
the code and the process; congratulations and keep going.]

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: Reworks of DML permission checks
Next: pgsql: Add support for TCPkeepalives on Windows, both for backend and