Re: [Postgres-xc-developers] how to fix EXECUTE DIRECT?

[Mason S. <mas...@en...>]

On 12/9/10 7:02 PM, Michael Paquier wrote:
> Hi all,
>
> I had a look at the code to try to understand how it could be able to 
> fix EXECUTE DIRECT.
> It is going to be needed to implement some HA features, and I believe 
> users would find this functionality useful if fixed.
>
> I am seeing two ways to fix it now.
> The first one could be to do the implementation out of Portal as we 
> did before moving XC query execution there.
> This was the first implementation of EXECUTE DIRECT that was done.
> It looks to be an easy solution, but if we have a look long-term, it 
> does not follow the will to move query execution inside portal.

I agree- it may be ok to do it outside and grab some old code, but I 
think we should try and use the current code and make it work.

>
> So here are the main lines I propose to fix that, with an 
> implementation inside portal.
>
> First, since DDL synchronize commit, it is possible Coordinators to 
> interact between themselves,
> so the query should be extended to:
> -- EXECUTE DIRECT ON (COORDINATOR num | NODE num, ...) query
> to be compared to what is in the current code:
> -- EXECUTE DIRECT ON (COORDINATOR | NODE num, ...) query
Sounds good.  What about

EXECUTE DIRECT ON ([COORDINATOR num[,num...]] [NODE num[,num...]]) query

maybe it is useful to see on all nodes at once with a single command.

BTW, in GridSQL we optionally include the source node number in the 
tuples returned. We should add something similar at some point (don't 
need this now though). Similarly, something like a NODE() function would 
be nice, to even be able to do SELECT *,NODE().

Are the coordinator numbers and node numbers are separate? That is, we 
can have both coordinator 1 and data node 1?

>
> Then, we have to modify query analyze in analyze.c.
> There is an API in the code called transformExecDirectStmt that 
> transforms the query and changes its shape.
> In the analyze part, you have to check if the query is launched 
> locally or not.
> If it is not local, change the node type to Remote Query to make it 
> run in ExecRemoteQuery when launching it.
>
> If it is local, you have to parse the query with parse_query and then 
> to analyze it with parse_analyze.
> After parsing and analyzing, change its node type to Query, to make it 
> launch locally.
>
> The difficult part of this implementation does not seem to be the 
> analyze and parsing part, it is in the planner.
> The question is:
> Should the query go through pgxc_planner or normal planner if it is local?
> Here is my proposal:
> pgxc_planner looks to be better but we have to put a flag (when 
> analyzing) in the query to be sure
> to launch the query on the correct nodes when determining execution 
> nodes in get_plan_nodes.
>
Yeah, I think we could go either way, but we know that with EXECUTE 
DIRECT it will always be a single step, so I think it is OK to put it in 
pgxc_planner. It should be pretty straight-forward though, I think we 
just need to additionally set step->exec_nodes, which we know already 
from parsing.  It may be that we need to extend this though to indicate 
to execute on specific Coordinators.

Overall, I don't think that this should be difficult to get working again.

Mason


> Regards,
>
> ------
> Michael Paquier
> http://michaelpq.users.sourceforge.net
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers


-- 
Mason Sharp
EnterpriseDB Corporation
The Enterprise Postgres Company


This e-mail message (and any attachment) is intended for the use of
the individual or entity to whom it is addressed. This message
contains information from EnterpriseDB Corporation that may be
privileged, confidential, or exempt from disclosure under applicable
law. If you are not the intended recipient or authorized to receive
this for the intended recipient, any use, dissemination, distribution,
retention, archiving, or copying of this communication is strictly
prohibited. If you have received this e-mail in error, please notify
the sender immediately by reply e-mail and delete this message.