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

Hmm...  I thought it will be reasonable enough just to allow SELECT 
(and COMMIT/ABORT) statement in EXECUTE DIRECT semantics.   Also, 
because we've changed the infrastructure of aggregate functions, I agree 
it will not safe enough to run such functions just in the coordinator. 
  We need an infrastructure as Benny pointed out:

SELECT count(*) from A, A;

Because EXECUTE DIRECT is just for housekeeping usage, I think it will 
also be reasonable to put some restriction which is sufficient for the 
dedicated use.

In this case, because 2PC recovery does not need aggregate, I think we 
can have this as is.

Regards;
---
Koichi

(2010年12月17日 07:09), Mason Sharp wrote:
> On 12/16/10 1:51 AM, Michael Paquier wrote:
>> Hi all,
>>
>> I extended the patch so as to be able to launch utilities on targeted
>> nodes (datanodes and Coordinators).
>> EXECUTE DIRECT is still restricted for UPDATE and DELETE.
>> And it is still not possible to launch a query on the local
>> Coordinator without spreading it to the other nodes.
>>
>> With this patch, in the case of a 2PC transaction that is partially
>> committed or partially aborted in the cluster,
>> EXECUTE DIRECT can be used to target specific nodes where to send a
>> COMMIT PREPARED or ABORT PREPARED.
>>
>> This is definitely useful for HA features and recovery also.
>>
>
> Michael,
>
> in pgxc_planner(), is that block of code for only when executing on a
> local coordinator?  Could it be safely handled above the switch()
> statement? I mean, if it is EXECUTE DIRECT, we just want to pass down
> the SQL string and have it executed as is.
>
> I ran some brief tests.
>
> DBT1=# EXECUTE DIRECT on NODE 1 'select count(*) from orders';
>    count
> -------
>     1269
> (1 row)
>
> DBT1=# EXECUTE DIRECT on NODE 2 'select count(*) from orders';
>    count
> -------
>     1332
> (1 row)
>
> DBT1=# EXECUTE DIRECT on NODE 1,2 'select count(*) from orders';
>    count
> -------
>     2601
> (1 row)
>
>
> For this last one, I expected to see two rows. That is, it passes down
> the exact SQL string, then shows the results of each. It looks like it
> is hooking into our general planning. We don't want the aggregate
> managed on the coordinator (hmmm, although it may open up interesting
> ideas in the future...).
>
> Similarly, something is not quite right with group by:
>
> DBT1=# EXECUTE DIRECT on NODE 1,2 'select o_status, count(*) from orders
> group by o_status';
> ERROR:  unrecognized node type: 656
>
>
> DBT1=# EXECUTE DIRECT on NODE 2 'select o_status, count(*) from orders
> group by o_status';
>    o_status | count
> ----------+-------
>             |  1332
> (1 row)
>
> Here, too, I think we should just get the results as if 'select
> o_status, count(*) from orders group by o_status' was executed on each
> node, all thrown together in the results (long term we could add an
> optional NODE column, like GridSQL).
>
> Perhaps this helps simplify things a bit.
>
> Thanks,
>
> Mason
>
>
>> Thanks,
>>
>> --
>> Michael Paquier
>> http://michaelpq.users.sourceforge.net
>>
>
>