postgres-xc-developers Mailing List for Postgres-XC

Thanks a lot for the update.   This will be committed in the earliest occasion.

Best;
---
Koichi Suzuki

2014/09/16 11:35、Wang Diancheng <dia...@gm...> のメール：

> Hi,
> 
> it lead to following statement crash:
> 
> clean connection to all force for regression;
> 
> patch attached.
> 
> diff --git a/src/backend/pgxc/pool/poolcomm.c b/src/backend/pgxc/pool/poolcomm.c
> index 02d67f3..b775649 100644
> --- a/src/backend/pgxc/pool/poolcomm.c
> +++ b/src/backend/pgxc/pool/poolcomm.c
> @@ -778,7 +778,7 @@ pool_recvpids(PoolPort *port, int **pids)
> 	{
> 		int n;
> 		memcpy(&n, buf + 5 + i * sizeof(int), sizeof(int));
> -		*pids[i] = ntohl(n);
> +		(*pids)[i] = ntohl(n);
> 	}
> 	return n32;
> 
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk_______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

Hi,

it lead to following statement crash:

clean connection to all force for regression;

patch attached.

On Tue, Sep 9, 2014 at 4:30 PM, Luyuanfei <ka...@hu...> wrote:
> /*
> * cost_remotequery
> * As of now the function just sets the costs to 0 to make this path the
> * cheapest.
> * PGXC_TODO: Ideally, we should estimate the costs of network transfer from
> * datanodes and any datanode costs involved.
> */
> It's very useful to some statement such as join or subquery.
In short, no. And I am not aware of anybody working in this area for
this project. Any patch would need a paper or research made in this
area to start on good basis IMO. Even without researches in this area,
I imagine that we'd finish for sure with a set of cost parameters that
can be set per-node (you don't want to have the same network cost for
a node on local network and another one thousands of miles away) and
that the planner could use those parameters when evaluating a plan
using an equal qual on an index used for hash. Another problem is that
we need a good idea of how they compare to other cost parameters to
avoid unbalanced plans. The issue remaining is then what are those
parameters, and what they symbolize.

> When you want reliability, choose Perforce.
Not much sure about that. Git is more appealing with its decentralized system.
-- 
Michael

There is a comment about function cost_remotequery as following:

/*
* cost_remotequery
* As of now the function just sets the costs to 0 to make this path the
* cheapest.
* PGXC_TODO: Ideally, we should estimate the costs of network transfer from
* datanodes and any datanode costs involved.
*/

It's very useful to some statement such as join or subquery.

Yours sincerely

Kaka Lu