postgres-xc-general Mailing List for Postgres-XC

Dear Friends,

Does anyone know a way for me to write this:
CREATE UNIQUE INDEX mdl_backcont_bac_uix ON mdl_backup_controllers USING
btree (backupid);

distributed in various DataNodes?

Best Regards
Afonso Bione

I Just tested with pgxc 1.1 and as you said Koichi,  it works great. :-)

Thanks.
Kristian


2013/8/7 Kristian Bruun <kri...@gm...>

> I used pgxc 1.0.3, patched with
> https://www.stormdb.com/sites/default/files/downloads/postgis_xc.patchand with postgis intalled.
>
> Maybe I did something wrong in the configuration phase. I followed the
> guide from https://www.stormdb.com/content/enabling-postgis-postgres-xc
>
> So basically what i have done is (all running on the same node):
> *$ initgtm -D gtm -Z gtm
> $ initdb -D c1 --nodename=coord1
> $ initdb -D n1 --nodename=dnode1
> *
>
> *$ cat >> /home/postgresxc/pgxc/gtm/gtm.conf << EOF
> nodename = 'gtm'
> port = 20001
> EOF
> $
> $ cat >> /home/postgresxc/pgxc/c1/postgresql.conf << EOF
> gtm_port = 20001
> port = 20004
> pooler_port = 20008
> EOF
> $
> $ cat >> /home/postgresxc/pgxc/n1/postgresql.conf << EOF
> gtm_port = 20001
> port = 20006
> EOF
> $
> **$ gtm_ctl start -Z gtm -D data-gtm
> **$ pg_ctl start -D data-c1 -Z coordinator*
> $ psql -p 20001 -d postgres*
> *# create database myspatial;
> # \c myspstial
>
> Now if I run "create extension postgis;" or "create table spatial_ref_sys2 ...." i get the error.
>
> Am i missing something completely fundamental here?
>
> Anyway, i'll give it a try on pgxc 1.1 and let you know the result.
>
> Thanks.
>
> Kristian
>
> **
>
>
> 2013/8/7 Koichi Suzuki <koi...@gm...>
>
>> What version did you use?   I tested this statement with the latest 1.1
>> branch and found it runs successfully as follows:
>>
>> PGXC$ Psql
>> Selected coord3.
>> psql (PGXC 1.1beta, based on PG 9.2.4)
>> Type "help" for help.
>>
>> koichi=# CREATE TABLE spatial_ref_sys2 (
>> koichi(#           srid integer not null primary key
>> koichi(#         check (srid > 0 and srid <= 998999),
>> koichi(#           auth_name varchar(2048),
>> koichi(#           auth_srid integer,
>> koichi(#           srtext varchar(2048),
>> koichi(#           proj4text varchar(2048)
>> koichi(#  );
>> NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
>> "spatial_ref_sys2_pkey" for table "spatial_ref_sys2"
>> CREATE TABLE
>> koichi=# select * from spatial_ref_sys2 ;
>>  srid | auth_name | auth_srid | srtext | proj4text
>> ------+-----------+-----------+--------+-----------
>> (0 rows)
>>
>> koichi=# \d spatial_ref_sys2
>>          Table "public.spatial_ref_sys2"
>>   Column   |          Type           | Modifiers
>> -----------+-------------------------+-----------
>>  srid      | integer                 | not null
>>  auth_name | character varying(2048) |
>>  auth_srid | integer                 |
>>  srtext    | character varying(2048) |
>>  proj4text | character varying(2048) |
>> Indexes:
>>     "spatial_ref_sys2_pkey" PRIMARY KEY, btree (srid)
>> Check constraints:
>>     "spatial_ref_sys2_srid_check" CHECK (srid > 0 AND srid <= 998999)
>>
>> koichi=#
>>
>> Regards;
>> ---
>> Koichi Suzuki
>>
>>
>> 2013/8/6 Kristian Bruun <kri...@gm...>
>>
>>> After digging more into to the problem, it seems like it's not postgis
>>> that's causing the problem, but something else.
>>>
>>> When I run the following command:
>>>
>>> CREATE TABLE spatial_ref_sys1 (
>>>           srid integer,
>>>           auth_name varchar(2048),
>>>           auth_srid integer,
>>>           srtext varchar(2048),
>>>           proj4text varchar(2048)
>>>  );
>>>
>>> It completes successfully, but running the same command where I specify
>>> the primary key
>>>
>>> CREATE TABLE spatial_ref_sys2 (
>>>           srid integer not null primary key
>>>         check (srid > 0 and srid <= 998999),
>>>           auth_name varchar(2048),
>>>           auth_srid integer,
>>>           srtext varchar(2048),
>>>           proj4text varchar(2048)
>>>  );
>>>
>>> it gives the *"server process (PID 9251) was terminated by signal 11:
>>> Segmentation fault" *error.
>>>
>>> Maybe this can help finding out what the problem might be.
>>>
>>> Regards,
>>> Kristian
>>>
>>>
>>>
>>> 2013/8/6 Andrei Martsinchyk <and...@gm...>
>>>
>>>> The tutorial was written some time back and may be out of date.
>>>> Hope we will find some time to look into and update the article.
>>>> The patch does have side effects, it is recommended to revert it after
>>>> installing.
>>>>
>>>>
>>>> 2013/8/6 鈴木 幸市 <ko...@in...>
>>>>
>>>>> I'm interested if the patch in the page does not have bad side
>>>>> effects.   It changes some of the error handling in XC core.
>>>>>
>>>>> Regards;
>>>>> ---
>>>>> Koichi Suzuki
>>>>>
>>>>> On 2013/08/06, at 10:21, Michael Paquier <mic...@gm...>
>>>>> wrote:
>>>>>
>>>>> > On Tue, Aug 6, 2013 at 9:56 AM, Koichi Suzuki <koi...@gm...>
>>>>> wrote:
>>>>> >> Hi,
>>>>> >>
>>>>> >> I think Mason Sharp has something on it.
>>>>> > And here you go...
>>>>> > https://www.stormdb.com/content/enabling-postgis-postgres-xc
>>>>> > --
>>>>> > Michael
>>>>> >
>>>>> >
>>>>> ------------------------------------------------------------------------------
>>>>> > Get your SQL database under version control now!
>>>>> > Version control is standard for application code, but databases
>>>>> havent
>>>>> > caught up. So what steps can you take to put your SQL databases under
>>>>> > version control? Why should you start doing it? Read more to find
>>>>> out.
>>>>> >
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>>>> > _______________________________________________
>>>>> > Postgres-xc-general mailing list
>>>>> > Pos...@li...
>>>>> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Get your SQL database under version control now!
>>>>> Version control is standard for application code, but databases havent
>>>>> caught up. So what steps can you take to put your SQL databases under
>>>>> version control? Why should you start doing it? Read more to find out.
>>>>>
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Postgres-xc-general mailing list
>>>>> Pos...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Andrei Martsinchyk
>>>>
>>>> StormDB - http://www.stormdb.com
>>>> The Database Cloud
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Get your SQL database under version control now!
>>>> Version control is standard for application code, but databases havent
>>>> caught up. So what steps can you take to put your SQL databases under
>>>> version control? Why should you start doing it? Read more to find out.
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Postgres-xc-general mailing list
>>>> Pos...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Get your SQL database under version control now!
>>> Version control is standard for application code, but databases havent
>>> caught up. So what steps can you take to put your SQL databases under
>>> version control? Why should you start doing it? Read more to find out.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Postgres-xc-general mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>
>>>
>>
>

I used pgxc 1.0.3, patched with
https://www.stormdb.com/sites/default/files/downloads/postgis_xc.patch and
with postgis intalled.

Maybe I did something wrong in the configuration phase. I followed the
guide from https://www.stormdb.com/content/enabling-postgis-postgres-xc

So basically what i have done is (all running on the same node):
*$ initgtm -D gtm -Z gtm
$ initdb -D c1 --nodename=coord1
$ initdb -D n1 --nodename=dnode1
*

*$ cat >> /home/postgresxc/pgxc/gtm/gtm.conf << EOF
nodename = 'gtm'
port = 20001
EOF
$
$ cat >> /home/postgresxc/pgxc/c1/postgresql.conf << EOF
gtm_port = 20001
port = 20004
pooler_port = 20008
EOF
$
$ cat >> /home/postgresxc/pgxc/n1/postgresql.conf << EOF
gtm_port = 20001
port = 20006
EOF
$
**$ gtm_ctl start -Z gtm -D data-gtm
**$ pg_ctl start -D data-c1 -Z coordinator*
$ psql -p 20001 -d postgres*
*# create database myspatial;
# \c myspstial

Now if I run "create extension postgis;" or "create table
spatial_ref_sys2 ...." i get the error.

Am i missing something completely fundamental here?

Anyway, i'll give it a try on pgxc 1.1 and let you know the result.

Thanks.

Kristian

**


2013/8/7 Koichi Suzuki <koi...@gm...>

> What version did you use?   I tested this statement with the latest 1.1
> branch and found it runs successfully as follows:
>
> PGXC$ Psql
> Selected coord3.
> psql (PGXC 1.1beta, based on PG 9.2.4)
> Type "help" for help.
>
> koichi=# CREATE TABLE spatial_ref_sys2 (
> koichi(#           srid integer not null primary key
> koichi(#         check (srid > 0 and srid <= 998999),
> koichi(#           auth_name varchar(2048),
> koichi(#           auth_srid integer,
> koichi(#           srtext varchar(2048),
> koichi(#           proj4text varchar(2048)
> koichi(#  );
> NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
> "spatial_ref_sys2_pkey" for table "spatial_ref_sys2"
> CREATE TABLE
> koichi=# select * from spatial_ref_sys2 ;
>  srid | auth_name | auth_srid | srtext | proj4text
> ------+-----------+-----------+--------+-----------
> (0 rows)
>
> koichi=# \d spatial_ref_sys2
>          Table "public.spatial_ref_sys2"
>   Column   |          Type           | Modifiers
> -----------+-------------------------+-----------
>  srid      | integer                 | not null
>  auth_name | character varying(2048) |
>  auth_srid | integer                 |
>  srtext    | character varying(2048) |
>  proj4text | character varying(2048) |
> Indexes:
>     "spatial_ref_sys2_pkey" PRIMARY KEY, btree (srid)
> Check constraints:
>     "spatial_ref_sys2_srid_check" CHECK (srid > 0 AND srid <= 998999)
>
> koichi=#
>
> Regards;
> ---
> Koichi Suzuki
>
>
> 2013/8/6 Kristian Bruun <kri...@gm...>
>
>> After digging more into to the problem, it seems like it's not postgis
>> that's causing the problem, but something else.
>>
>> When I run the following command:
>>
>> CREATE TABLE spatial_ref_sys1 (
>>           srid integer,
>>           auth_name varchar(2048),
>>           auth_srid integer,
>>           srtext varchar(2048),
>>           proj4text varchar(2048)
>>  );
>>
>> It completes successfully, but running the same command where I specify
>> the primary key
>>
>> CREATE TABLE spatial_ref_sys2 (
>>           srid integer not null primary key
>>         check (srid > 0 and srid <= 998999),
>>           auth_name varchar(2048),
>>           auth_srid integer,
>>           srtext varchar(2048),
>>           proj4text varchar(2048)
>>  );
>>
>> it gives the *"server process (PID 9251) was terminated by signal 11:
>> Segmentation fault" *error.
>>
>> Maybe this can help finding out what the problem might be.
>>
>> Regards,
>> Kristian
>>
>>
>>
>> 2013/8/6 Andrei Martsinchyk <and...@gm...>
>>
>>> The tutorial was written some time back and may be out of date.
>>> Hope we will find some time to look into and update the article.
>>> The patch does have side effects, it is recommended to revert it after
>>> installing.
>>>
>>>
>>> 2013/8/6 鈴木 幸市 <ko...@in...>
>>>
>>>> I'm interested if the patch in the page does not have bad side effects.
>>>>   It changes some of the error handling in XC core.
>>>>
>>>> Regards;
>>>> ---
>>>> Koichi Suzuki
>>>>
>>>> On 2013/08/06, at 10:21, Michael Paquier <mic...@gm...>
>>>> wrote:
>>>>
>>>> > On Tue, Aug 6, 2013 at 9:56 AM, Koichi Suzuki <koi...@gm...>
>>>> wrote:
>>>> >> Hi,
>>>> >>
>>>> >> I think Mason Sharp has something on it.
>>>> > And here you go...
>>>> > https://www.stormdb.com/content/enabling-postgis-postgres-xc
>>>> > --
>>>> > Michael
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------------
>>>> > Get your SQL database under version control now!
>>>> > Version control is standard for application code, but databases havent
>>>> > caught up. So what steps can you take to put your SQL databases under
>>>> > version control? Why should you start doing it? Read more to find out.
>>>> >
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>>> > _______________________________________________
>>>> > Postgres-xc-general mailing list
>>>> > Pos...@li...
>>>> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>> >
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Get your SQL database under version control now!
>>>> Version control is standard for application code, but databases havent
>>>> caught up. So what steps can you take to put your SQL databases under
>>>> version control? Why should you start doing it? Read more to find out.
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Postgres-xc-general mailing list
>>>> Pos...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>>
>>>
>>>
>>>
>>> --
>>> Andrei Martsinchyk
>>>
>>> StormDB - http://www.stormdb.com
>>> The Database Cloud
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Get your SQL database under version control now!
>>> Version control is standard for application code, but databases havent
>>> caught up. So what steps can you take to put your SQL databases under
>>> version control? Why should you start doing it? Read more to find out.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Postgres-xc-general mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases havent
>> caught up. So what steps can you take to put your SQL databases under
>> version control? Why should you start doing it? Read more to find out.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>
>>
>

What version did you use?   I tested this statement with the latest 1.1
branch and found it runs successfully as follows:

PGXC$ Psql
Selected coord3.
psql (PGXC 1.1beta, based on PG 9.2.4)
Type "help" for help.

koichi=# CREATE TABLE spatial_ref_sys2 (
koichi(#           srid integer not null primary key
koichi(#         check (srid > 0 and srid <= 998999),
koichi(#           auth_name varchar(2048),
koichi(#           auth_srid integer,
koichi(#           srtext varchar(2048),
koichi(#           proj4text varchar(2048)
koichi(#  );
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"spatial_ref_sys2_pkey" for table "spatial_ref_sys2"
CREATE TABLE
koichi=# select * from spatial_ref_sys2 ;
 srid | auth_name | auth_srid | srtext | proj4text
------+-----------+-----------+--------+-----------
(0 rows)

koichi=# \d spatial_ref_sys2
         Table "public.spatial_ref_sys2"
  Column   |          Type           | Modifiers
-----------+-------------------------+-----------
 srid      | integer                 | not null
 auth_name | character varying(2048) |
 auth_srid | integer                 |
 srtext    | character varying(2048) |
 proj4text | character varying(2048) |
Indexes:
    "spatial_ref_sys2_pkey" PRIMARY KEY, btree (srid)
Check constraints:
    "spatial_ref_sys2_srid_check" CHECK (srid > 0 AND srid <= 998999)

koichi=#

Regards;
---
Koichi Suzuki


2013/8/6 Kristian Bruun <kri...@gm...>

> After digging more into to the problem, it seems like it's not postgis
> that's causing the problem, but something else.
>
> When I run the following command:
>
> CREATE TABLE spatial_ref_sys1 (
>           srid integer,
>           auth_name varchar(2048),
>           auth_srid integer,
>           srtext varchar(2048),
>           proj4text varchar(2048)
>  );
>
> It completes successfully, but running the same command where I specify
> the primary key
>
> CREATE TABLE spatial_ref_sys2 (
>           srid integer not null primary key
>         check (srid > 0 and srid <= 998999),
>           auth_name varchar(2048),
>           auth_srid integer,
>           srtext varchar(2048),
>           proj4text varchar(2048)
>  );
>
> it gives the *"server process (PID 9251) was terminated by signal 11:
> Segmentation fault" *error.
>
> Maybe this can help finding out what the problem might be.
>
> Regards,
> Kristian
>
>
>
> 2013/8/6 Andrei Martsinchyk <and...@gm...>
>
>> The tutorial was written some time back and may be out of date.
>> Hope we will find some time to look into and update the article.
>> The patch does have side effects, it is recommended to revert it after
>> installing.
>>
>>
>> 2013/8/6 鈴木 幸市 <ko...@in...>
>>
>>> I'm interested if the patch in the page does not have bad side effects.
>>>   It changes some of the error handling in XC core.
>>>
>>> Regards;
>>> ---
>>> Koichi Suzuki
>>>
>>> On 2013/08/06, at 10:21, Michael Paquier <mic...@gm...>
>>> wrote:
>>>
>>> > On Tue, Aug 6, 2013 at 9:56 AM, Koichi Suzuki <koi...@gm...>
>>> wrote:
>>> >> Hi,
>>> >>
>>> >> I think Mason Sharp has something on it.
>>> > And here you go...
>>> > https://www.stormdb.com/content/enabling-postgis-postgres-xc
>>> > --
>>> > Michael
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Get your SQL database under version control now!
>>> > Version control is standard for application code, but databases havent
>>> > caught up. So what steps can you take to put your SQL databases under
>>> > version control? Why should you start doing it? Read more to find out.
>>> >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>> > _______________________________________________
>>> > Postgres-xc-general mailing list
>>> > Pos...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>> >
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Get your SQL database under version control now!
>>> Version control is standard for application code, but databases havent
>>> caught up. So what steps can you take to put your SQL databases under
>>> version control? Why should you start doing it? Read more to find out.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Postgres-xc-general mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>
>>
>>
>>
>> --
>> Andrei Martsinchyk
>>
>> StormDB - http://www.stormdb.com
>> The Database Cloud
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases havent
>> caught up. So what steps can you take to put your SQL databases under
>> version control? Why should you start doing it? Read more to find out.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>
>>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
>

Your questions are already answered, here are just some additions.

On Wed, Aug 7, 2013 at 2:56 PM, amul sul <sul...@ya...> wrote:
> 5. Not allowed Modifying distribution columns definition
This is true in 1.0, not in 1.1 and above. It is possible to change
the distribution type of a table with ALTER TABLE in the upcoming 1.1.
Syntax is the same as CREATE TABLE.
http://postgres-xc.sourceforge.net/docs/1_1_beta/sql-altertable.html

> 5bis. Modifying distribution column values
This needs tuple relocation... Don't count on that.

>
> I am not pretty clear about all those point, so need your help.
> My questions are as follow:
>
> Is distribution on table is possible in following condition ?
>         1. relation(table) has Primary key and Foreign key(REFERENCE column)
> and both are different?
In this case, you can distribute the child table on if column and
table have the same data type, and their data is located on the same
nodes such as they perfectly map. If this is not the case, you need to
replicate the parent table referenced.

>         2. If primary key is on ( col1, col2) and Foreign key is only on
> (col2) is this O.K, if PRIMARY key is used as distribution column.
If parent is distributed with col2, you could be able to enforce the
constraint evaluation to Datanodes if child is also distributed with
col2, and that the data of parent and child is located on the same
datanodes.
In other cases, replicate the parent.

>         3. If relation has more than one Foreign key (on col1 and col2)
As long as the parent is distributed with one column included in the
foreign key, it is fine to distribute the child table with the same
column. Child and parent would need once again to have their data
located on the same nodes.

In case 2&3, I am wondering if XC algorithm is smart enough to allow
table creation though in those cases... Comments on that?

> I think it not possible distribute table in such condition, in this case is
> this best way to distributed by ROUND ROBIN or REPLECATE relations?
Avoid ROUND ROBIN if you want to have control on the data distributed.
-- 
Michael

Hi Amul,
Please check out this video http://www.youtube.com/watch?v=g_9CYat8nkY. The
video explains various impacts the distribution/replication has in XC.


On Wed, Aug 7, 2013 at 11:50 AM, Koichi Suzuki <koi...@gm...>wrote:

> Hello Amul;
>
>
> Welcome to Postgres-XC community.
>
>
> 2013/8/7 amul sul <sul...@ya...>
>
>> Hello ALL,****
>>
>> I need little help, to migrated Postgres database to the PGXC.****
>>
>> While creating database, I want to best possible way of relations should
>> distribute and/or replicated, Primary aim to achieve to optimum performance.
>>
>
> Some description on table distribution/replication will be found in PGCon
> tutorial material available at our Wiki page
> http://postgresxc.wikia.com/wiki/Postgres-XC_Wiki.
>
>
>> ****
>>
>> But we need to consider following constrain mention in documentation. ***
>> *
>>
>> 1. In distributed tables, UNIQUE constraints must include the
>> distribution column of the table.
>>
>
> Yes, because we cannot enforce unique constraints in this case unless we
> do not have global index.   It is not practical to visit all the datanodes
> to enforce this.
>
>
>>  ****
>> 2. in UNIQUE constraint, distribution column must be included in PRIMARY
>> KEY. Other restrictions apply to PRIMARY KEY too.
>>
>
> This is by the same reason as 1.
>
>
>> ****
>> 3. REFERENCE must be the distribution column while creating Foreign key
>> in relation. In this case, we cannot add PRIMARY KEY to other column in
>> relation because PRIMARY KEY must be the distribution column as well.
>>
>
> This is also by the same reason as 1.  We may be able to support this
> without such global object management if referred column is a primary key
> or set of referred column includes a primary key.
>
>
>> ****
>> 4. With REFERENCES integrity needs to be the distribution column, it is
>> Postgres-XC's restriction that we cannot specify more than one columns with
>> REFERENCES constraint.
>>
>
> See above.
>
>
>>
> ****
>> 5. Not allowed Modifying distribution columns definition and Modifying
>> distribution column values
>>
>
> When distribution column value is altered, we need to move this row to
> somewhere else.  It is not simple so far to track this to handle following
> update statement correctly.
>
> ****
>>
>> I am not pretty clear about all those point, so need your help.****
>> My questions are as follow:****
>>
>> Is distribution on table is possible in following condition ?****
>>         1. relation(table) has Primary key and Foreign key(REFERENCE
>> column) and both are different?****
>>         2. If primary key is on ( col1, col2) and Foreign key is only on
>> (col2) is this O.K, if PRIMARY key is used as distribution column. ****
>>         3. If relation has more than one Foreign key (on col1 and col2) *
>> ***
>>
>> I think it not possible distribute table in such condition, in this case
>> is this best way to distributed by ROUND ROBIN or REPLECATE relations?
>>
>
> Round robin is not a good idea.   Make referred table "replicated" will
> fix the above problems.
>
> Hope they help.
>
> Regards;
> ---
> Koichi Suzuki
>
>
>
>> ****
>>
>> Thoughts?  Comments?****
>>
>> Thank you.****
>>
>> Regards****
>>  Amul Sul****
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>
>>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
>


-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Postgres Database Company

Hello Amul;


Welcome to Postgres-XC community.


2013/8/7 amul sul <sul...@ya...>

> Hello ALL,****
>
> I need little help, to migrated Postgres database to the PGXC.****
>
> While creating database, I want to best possible way of relations should
> distribute and/or replicated, Primary aim to achieve to optimum performance.
>

Some description on table distribution/replication will be found in PGCon
tutorial material available at our Wiki page
http://postgresxc.wikia.com/wiki/Postgres-XC_Wiki.


> ****
>
> But we need to consider following constrain mention in documentation. ****
>
> 1. In distributed tables, UNIQUE constraints must include the distribution
> column of the table.
>

Yes, because we cannot enforce unique constraints in this case unless we do
not have global index.   It is not practical to visit all the datanodes to
enforce this.


> ****
> 2. in UNIQUE constraint, distribution column must be included in PRIMARY
> KEY. Other restrictions apply to PRIMARY KEY too.
>

This is by the same reason as 1.


> ****
> 3. REFERENCE must be the distribution column while creating Foreign key in
> relation. In this case, we cannot add PRIMARY KEY to other column in
> relation because PRIMARY KEY must be the distribution column as well.
>

This is also by the same reason as 1.  We may be able to support this
without such global object management if referred column is a primary key
or set of referred column includes a primary key.


> ****
> 4. With REFERENCES integrity needs to be the distribution column, it is
> Postgres-XC's restriction that we cannot specify more than one columns with
> REFERENCES constraint.
>

See above.


>
****
> 5. Not allowed Modifying distribution columns definition and Modifying
> distribution column values
>

When distribution column value is altered, we need to move this row to
somewhere else.  It is not simple so far to track this to handle following
update statement correctly.

****
>
> I am not pretty clear about all those point, so need your help.****
> My questions are as follow:****
>
> Is distribution on table is possible in following condition ?****
>         1. relation(table) has Primary key and Foreign key(REFERENCE
> column) and both are different?****
>         2. If primary key is on ( col1, col2) and Foreign key is only on
> (col2) is this O.K, if PRIMARY key is used as distribution column. ****
>         3. If relation has more than one Foreign key (on col1 and col2) **
> **
>
> I think it not possible distribute table in such condition, in this case
> is this best way to distributed by ROUND ROBIN or REPLECATE relations?
>

Round robin is not a good idea.   Make referred table "replicated" will fix
the above problems.

Hope they help.

Regards;
---
Koichi Suzuki



> ****
>
> Thoughts?  Comments?****
>
> Thank you.****
>
> Regards****
> Amul Sul****
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
>

Hello ALL,
 
I need little help, to migrated Postgres
database to the PGXC.
 
While creating database, I want to best
possible way of relations should distribute and/or replicated, Primary aim to
achieve to optimum performance.
 
But we need to consider following
constrain mention in documentation. 
 
1. In distributed tables, UNIQUE
constraints must include the distribution column of the table. 
2. in UNIQUE constraint, distribution
column must be included in PRIMARY KEY. Other restrictions apply to PRIMARY KEY
too.
3. REFERENCE must be the distribution
column while creating Foreign key in relation. In this case, we cannot add
PRIMARY KEY to other column in relation because PRIMARY KEY must be the
distribution column as well.
4. With REFERENCES integrity needs to be
the distribution column, it is Postgres-XC's restriction that we cannot specify
more than one columns with REFERENCES constraint.
5. Not allowed Modifying distribution
columns definition and Modifying distribution column values
 
I am not pretty clear about all those
point, so need your help.
My questions are as follow:
 
Is distribution on table is possible in
following condition ?
        1.
relation(table) has Primary key and Foreign key(REFERENCE column) and both are
different?
        2.
If primary key is on ( col1, col2) and Foreign key is only on (col2) is this
O.K, if PRIMARY key is used as distribution column. 
        3.
If relation has more than one Foreign key (on col1 and col2) 
 
I think it not possible distribute table
in such condition, in this case is this best way to distributed by ROUND ROBIN
or REPLECATE relations?
 
Thoughts?  Comments?
 
Thank you.
 
Regards
Amul Sul

On Wed, Aug 7, 2013 at 11:33 AM, Koichi Suzuki <koi...@gm...> wrote:
> Postgres-XC sourceforge repository has been upgraded successfully.   There
> are no change in development page URL.    GIT repository URL changed.
The new URL can be found here:
http://sourceforge.net/p/postgres-xc/postgres-xc/ci/master/tree/
And you can use git protocol:
git clone git://git.code.sf.net/p/postgres-xc/postgres-xc
postgres-xc-postgres-xc
or https to clone the repository:
git clone http://git.code.sf.net/p/postgres-xc/postgres-xc
postgres-xc-postgres-xc

>
> Top page of the development page will have "GIT" tag, where you can choose a
> repository (postgres-xc, in this case) then you will get URLs for RW, RO and
> HTTPS, depending your privilege to the repo.
RW = read-write
RO = read-only
HTTP = can be both depending on your status on the project concerned

> I've not tested if we can continue to use local repo just with changing
> configuration.
What do you mean by that? You just need to change the link to remote
folder by either running for example "git remote set-url" or even
setting directly .git/config. This does not impact your local
environment, the commits SHA1 as well as the commit history are still
the same.

> Hope they provide faster link.
It looks that the new layer of their website is very github-like. This
is not necessarily a bad thing :) https is something people have
wanted in sourceforge for years... Definitely useful for people hidden
behind a company firewall.
-- 
Michael

Hello;

Postgres-XC sourceforge repository has been upgraded successfully.   There
are no change in development page URL.    GIT repository URL changed.

Top page of the development page will have "GIT" tag, where you can choose
a repository (postgres-xc, in this case) then you will get URLs for RW, RO
and HTTPS, depending your privilege to the repo.

I've not tested if we can continue to use local repo just with changing
configuration.

Hope they provide faster link.

Good Luck;
---
Koichi Suzuki