postgres-xc-general Mailing List for Postgres-XC (Page 52)

Hi Koichi,

Not specifically PostgreSQL, using mysql, and we haven't benchmarked... 
We run an email marketing company (we basically DDOS ourselves by 
sending mails fast and receiving clicks back) and have about 20 pizzabox 
servers in one rack. Each pizzabox has about 5 VMs, most have an active 
db instance.

Using asynchronous DRBD, via a 1Gbps VPLS, we sync to the second 
location so we have a hot-standby for a server. The average traffic in 
our usecase is 100Mbps and we peak around 400Mbps during backups (the 
backupserver is also mirrored of course). I have _never_ seen issues 
with DRBD is this setting (and we failover regularly for maintenance of 
the hosts; only the VMs are synced). We used to have synchronous 
replication when the hosts were coupled together; no issues either. I 
have to say that our data is not required to be of 'bank quality' (using 
mysql/myisam will guarantee  that).

I have seen many more issues from upgrading from Debian Lenny to Debian 
Squeeze on our Dell R310. I/O performance seems to have lowered 
significantly, say 20% or 30% (more I/O related incidents since update). 
These are gut numbers because I have a hard time reproducing this (it 
only occurs when many users do many different things). We have not 
located that issue (to any driver, hw and/or kernel changes).

However. We basically are not using 50% of our hardware and it hurts my 
need for optimization.

David

On 11/06/2012 01:55 AM, Koichi Suzuki wrote:
> Does anybody has performance data for DRBD with PostgreSQL?   The
> following reports that the throughput will become almost half.
>
> http://archives.postgresql.org/pgsql-performance/2007-09/msg00118.php
>
> The article is posted about five years ago, though.
>
> Regards;
> ----------
> Koichi Suzuki
>
>
> 2012/11/6 Vladimir Stavrinov <vst...@gm...>:
>> On Mon, Nov 05, 2012 at 07:22:54PM +0300, Vladimir Stavrinov wrote:
>>
>>> solution is alliance of drbd + pacemaker + corosync. It is  very
>> Forgot to add in this team ipvs.
>>
>>
>> *****************************
>> ###  Vladimir Stavrinov
>> ###  vst...@gm...
>> *****************************
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general

-- 
let op: mijn email is gewijzigd naar da...@c0...

No, So far, views are only propagated to coordinators.   pgxc_*
catalogs will be found only at coordinators.   Depending upon objects,
CREATE/ALTER/DROP are propagated to datanodes as well.

View is a kind of exception.

Regards;
----------
Koichi Suzuki


2012/11/6 Tatsuo Ishii <is...@po...>:
> Thanks. Your answer cleared my question.
>
> BTW, the view created on the coordinator node should be copied to data
> nodes?  I couldn't find the view on the data nodes. If the answer is
> no, DDL executed on coordinator node is not copied to data node in
> Postgres-XC? CREATE TABLE seems to be copied to data node. Maybe
> CREATE VIEW is treated specially?
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp
>
>> Yes, the view works at coordinator locally.
>>
>> CREATE VIEW is propagated to all the coordinators so you should run it
>> only once at one of them.
>>
>> The reason I suggested EXECUTE DIRECT is user table looked involved in
>> the query.
>>
>> Regards;
>> ----------
>> Koichi Suzuki
>>
>>
>> 2012/11/6 Tatsuo Ishii <is...@po...>:
>>> Thanks. Your view works great! BTW, Should the view be executed on
>>> coordinator node? If so, I'm a little bit confused. Because you said:
>>>
>>>> Because pgxc_class and pg_class are both local to each node, oid is
>>>> also local.   To query correctly, they should be issued using EXECUTE
>>>> DIRECT statement.   Each EXECUTE DIRECT will return the result local
>>>> to each node.
>>>> 2012/11/6 Tatsuo Ishii <is...@po...>:
>>>>> I sent a query to coordinator node and got following result. Doesn't
>>>>> this means table "pgbench_accounts" distributed?
>>>>>
>>>>> test=# select * from pgxc_class as x join pg_class as c on x.pcrelid = c.oid where c.relname = 'pgbench_accounts';
>>>
>>>> pgxc_class has distribution definition of each table.    I'm using the
>>>> following views as a handy tool:
>>>>
>>>> ----
>>>> [koichi@linker:scripts]$ cat distr_view.sql
>>>> DROP VIEW IF EXISTS xc_table_distribution;
>>>>
>>>>
>>>> CREATE VIEW xc_table_distribution AS
>>>>
>>>> SELECT pg_class.relname relation,
>>>>        CASE
>>>>          WHEN pclocatortype = 'H' THEN 'Hash'
>>>>          WHEN pclocatortype = 'M' THEN 'Modulo'
>>>>          WHEN pclocatortype = 'N' THEN 'Round Robin'
>>>>          WHEN pclocatortype = 'R' THEN 'Replicate'
>>>>          ELSE 'Unknown'
>>>>        END AS distribution,
>>>>        pg_attribute.attname attname
>>>>     FROM pg_class, pgxc_class, pg_attribute
>>>>     WHERE pg_class.oid = pgxc_class.pcrelid
>>>>           and pg_class.oid = pg_attribute.attrelid
>>>>           and pgxc_class.pcattnum = pg_attribute.attnum
>>>>  UNION
>>>>
>>>> SELECT pg_class.relname relation,
>>>>        CASE
>>>>          WHEN pclocatortype = 'H' THEN 'Hash'
>>>>          WHEN pclocatortype = 'M' THEN 'Modulo'
>>>>          WHEN pclocatortype = 'N' THEN 'Round Robin'
>>>>          WHEN pclocatortype = 'R' THEN 'Replicate'
>>>>          ELSE 'Unknown'
>>>>        END AS distribution,
>>>>        '- none -' attname
>>>>    FROM pg_class, pgxc_class, pg_attribute
>>>>    WHERE pg_class.oid = pgxc_class.pcrelid
>>>>          and pg_class.oid = pg_attribute.attrelid
>>>>          and pgxc_class.pcattnum = 0
>>>>     ;
>>>>
>>>> COMMENT ON VIEW xc_table_distribution IS
>>>> 'View to show distribution/replication attribute of the given table.';
>>>>
>>>> [koichi@linker:scripts]$
>>>> ------
>>>>
>>>> Info for pgbench tables are as follows:
>>>> -----------
>>>> koichi=# select * from xc_table_distribution
>>>> koichi-# ;
>>>>      relation     | distribution | attname
>>>> ------------------+--------------+----------
>>>>  t                | Hash         | a
>>>>  pgbench_branches | Hash         | bid
>>>>  y                | Modulo       | a
>>>>  pgbench_tellers  | Hash         | bid
>>>>  pgbench_accounts | Hash         | bid
>>>>  x                | Round Robin  | - none -
>>>>  pgbench_history  | Hash         | bid
>>>>  s                | Replicate    | - none -
>>>> (8 rows)
>>>>
>>>> koichi=#
>>>> ------
>>>>
>>>> Hope it helps.
>>>>
>>>> Regards;
>>>> ----------
>>>> Koichi Suzuki
>>>>
>>>>
>>>> 2012/11/6 Tatsuo Ishii <is...@po...>:
>>>>>> One suggestion.   Because set bid value is relatively small, it may be
>>>>>> better to distribute tables using MODULO, not HASH.
>>>>>
>>>>> What is the distribution method when pgbench -k is used?
>>>>> --
>>>>> Tatsuo Ishii
>>>>> SRA OSS, Inc. Japan
>>>>> English: http://www.sraoss.co.jp/index_en.php
>>>>> Japanese: http://www.sraoss.co.jp

Thanks. Your answer cleared my question.

BTW, the view created on the coordinator node should be copied to data
nodes?  I couldn't find the view on the data nodes. If the answer is
no, DDL executed on coordinator node is not copied to data node in
Postgres-XC? CREATE TABLE seems to be copied to data node. Maybe
CREATE VIEW is treated specially?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

> Yes, the view works at coordinator locally.
> 
> CREATE VIEW is propagated to all the coordinators so you should run it
> only once at one of them.
> 
> The reason I suggested EXECUTE DIRECT is user table looked involved in
> the query.
> 
> Regards;
> ----------
> Koichi Suzuki
> 
> 
> 2012/11/6 Tatsuo Ishii <is...@po...>:
>> Thanks. Your view works great! BTW, Should the view be executed on
>> coordinator node? If so, I'm a little bit confused. Because you said:
>>
>>> Because pgxc_class and pg_class are both local to each node, oid is
>>> also local.   To query correctly, they should be issued using EXECUTE
>>> DIRECT statement.   Each EXECUTE DIRECT will return the result local
>>> to each node.
>>> 2012/11/6 Tatsuo Ishii <is...@po...>:
>>>> I sent a query to coordinator node and got following result. Doesn't
>>>> this means table "pgbench_accounts" distributed?
>>>>
>>>> test=# select * from pgxc_class as x join pg_class as c on x.pcrelid = c.oid where c.relname = 'pgbench_accounts';
>>
>>> pgxc_class has distribution definition of each table.    I'm using the
>>> following views as a handy tool:
>>>
>>> ----
>>> [koichi@linker:scripts]$ cat distr_view.sql
>>> DROP VIEW IF EXISTS xc_table_distribution;
>>>
>>>
>>> CREATE VIEW xc_table_distribution AS
>>>
>>> SELECT pg_class.relname relation,
>>>        CASE
>>>          WHEN pclocatortype = 'H' THEN 'Hash'
>>>          WHEN pclocatortype = 'M' THEN 'Modulo'
>>>          WHEN pclocatortype = 'N' THEN 'Round Robin'
>>>          WHEN pclocatortype = 'R' THEN 'Replicate'
>>>          ELSE 'Unknown'
>>>        END AS distribution,
>>>        pg_attribute.attname attname
>>>     FROM pg_class, pgxc_class, pg_attribute
>>>     WHERE pg_class.oid = pgxc_class.pcrelid
>>>           and pg_class.oid = pg_attribute.attrelid
>>>           and pgxc_class.pcattnum = pg_attribute.attnum
>>>  UNION
>>>
>>> SELECT pg_class.relname relation,
>>>        CASE
>>>          WHEN pclocatortype = 'H' THEN 'Hash'
>>>          WHEN pclocatortype = 'M' THEN 'Modulo'
>>>          WHEN pclocatortype = 'N' THEN 'Round Robin'
>>>          WHEN pclocatortype = 'R' THEN 'Replicate'
>>>          ELSE 'Unknown'
>>>        END AS distribution,
>>>        '- none -' attname
>>>    FROM pg_class, pgxc_class, pg_attribute
>>>    WHERE pg_class.oid = pgxc_class.pcrelid
>>>          and pg_class.oid = pg_attribute.attrelid
>>>          and pgxc_class.pcattnum = 0
>>>     ;
>>>
>>> COMMENT ON VIEW xc_table_distribution IS
>>> 'View to show distribution/replication attribute of the given table.';
>>>
>>> [koichi@linker:scripts]$
>>> ------
>>>
>>> Info for pgbench tables are as follows:
>>> -----------
>>> koichi=# select * from xc_table_distribution
>>> koichi-# ;
>>>      relation     | distribution | attname
>>> ------------------+--------------+----------
>>>  t                | Hash         | a
>>>  pgbench_branches | Hash         | bid
>>>  y                | Modulo       | a
>>>  pgbench_tellers  | Hash         | bid
>>>  pgbench_accounts | Hash         | bid
>>>  x                | Round Robin  | - none -
>>>  pgbench_history  | Hash         | bid
>>>  s                | Replicate    | - none -
>>> (8 rows)
>>>
>>> koichi=#
>>> ------
>>>
>>> Hope it helps.
>>>
>>> Regards;
>>> ----------
>>> Koichi Suzuki
>>>
>>>
>>> 2012/11/6 Tatsuo Ishii <is...@po...>:
>>>>> One suggestion.   Because set bid value is relatively small, it may be
>>>>> better to distribute tables using MODULO, not HASH.
>>>>
>>>> What is the distribution method when pgbench -k is used?
>>>> --
>>>> Tatsuo Ishii
>>>> SRA OSS, Inc. Japan
>>>> English: http://www.sraoss.co.jp/index_en.php
>>>> Japanese: http://www.sraoss.co.jp

Yes, the view works at coordinator locally.

CREATE VIEW is propagated to all the coordinators so you should run it
only once at one of them.

The reason I suggested EXECUTE DIRECT is user table looked involved in
the query.

Regards;
----------
Koichi Suzuki


2012/11/6 Tatsuo Ishii <is...@po...>:
> Thanks. Your view works great! BTW, Should the view be executed on
> coordinator node? If so, I'm a little bit confused. Because you said:
>
>> Because pgxc_class and pg_class are both local to each node, oid is
>> also local.   To query correctly, they should be issued using EXECUTE
>> DIRECT statement.   Each EXECUTE DIRECT will return the result local
>> to each node.
>> 2012/11/6 Tatsuo Ishii <is...@po...>:
>>> I sent a query to coordinator node and got following result. Doesn't
>>> this means table "pgbench_accounts" distributed?
>>>
>>> test=# select * from pgxc_class as x join pg_class as c on x.pcrelid = c.oid where c.relname = 'pgbench_accounts';
>
>> pgxc_class has distribution definition of each table.    I'm using the
>> following views as a handy tool:
>>
>> ----
>> [koichi@linker:scripts]$ cat distr_view.sql
>> DROP VIEW IF EXISTS xc_table_distribution;
>>
>>
>> CREATE VIEW xc_table_distribution AS
>>
>> SELECT pg_class.relname relation,
>>        CASE
>>          WHEN pclocatortype = 'H' THEN 'Hash'
>>          WHEN pclocatortype = 'M' THEN 'Modulo'
>>          WHEN pclocatortype = 'N' THEN 'Round Robin'
>>          WHEN pclocatortype = 'R' THEN 'Replicate'
>>          ELSE 'Unknown'
>>        END AS distribution,
>>        pg_attribute.attname attname
>>     FROM pg_class, pgxc_class, pg_attribute
>>     WHERE pg_class.oid = pgxc_class.pcrelid
>>           and pg_class.oid = pg_attribute.attrelid
>>           and pgxc_class.pcattnum = pg_attribute.attnum
>>  UNION
>>
>> SELECT pg_class.relname relation,
>>        CASE
>>          WHEN pclocatortype = 'H' THEN 'Hash'
>>          WHEN pclocatortype = 'M' THEN 'Modulo'
>>          WHEN pclocatortype = 'N' THEN 'Round Robin'
>>          WHEN pclocatortype = 'R' THEN 'Replicate'
>>          ELSE 'Unknown'
>>        END AS distribution,
>>        '- none -' attname
>>    FROM pg_class, pgxc_class, pg_attribute
>>    WHERE pg_class.oid = pgxc_class.pcrelid
>>          and pg_class.oid = pg_attribute.attrelid
>>          and pgxc_class.pcattnum = 0
>>     ;
>>
>> COMMENT ON VIEW xc_table_distribution IS
>> 'View to show distribution/replication attribute of the given table.';
>>
>> [koichi@linker:scripts]$
>> ------
>>
>> Info for pgbench tables are as follows:
>> -----------
>> koichi=# select * from xc_table_distribution
>> koichi-# ;
>>      relation     | distribution | attname
>> ------------------+--------------+----------
>>  t                | Hash         | a
>>  pgbench_branches | Hash         | bid
>>  y                | Modulo       | a
>>  pgbench_tellers  | Hash         | bid
>>  pgbench_accounts | Hash         | bid
>>  x                | Round Robin  | - none -
>>  pgbench_history  | Hash         | bid
>>  s                | Replicate    | - none -
>> (8 rows)
>>
>> koichi=#
>> ------
>>
>> Hope it helps.
>>
>> Regards;
>> ----------
>> Koichi Suzuki
>>
>>
>> 2012/11/6 Tatsuo Ishii <is...@po...>:
>>>> One suggestion.   Because set bid value is relatively small, it may be
>>>> better to distribute tables using MODULO, not HASH.
>>>
>>> What is the distribution method when pgbench -k is used?
>>> --
>>> Tatsuo Ishii
>>> SRA OSS, Inc. Japan
>>> English: http://www.sraoss.co.jp/index_en.php
>>> Japanese: http://www.sraoss.co.jp

Thanks. Your view works great! BTW, Should the view be executed on
coordinator node? If so, I'm a little bit confused. Because you said:

> Because pgxc_class and pg_class are both local to each node, oid is
> also local.   To query correctly, they should be issued using EXECUTE
> DIRECT statement.   Each EXECUTE DIRECT will return the result local
> to each node.
> 2012/11/6 Tatsuo Ishii <is...@po...>:
>> I sent a query to coordinator node and got following result. Doesn't
>> this means table "pgbench_accounts" distributed?
>>
>> test=# select * from pgxc_class as x join pg_class as c on x.pcrelid = c.oid where c.relname = 'pgbench_accounts';

> pgxc_class has distribution definition of each table.    I'm using the
> following views as a handy tool:
> 
> ----
> [koichi@linker:scripts]$ cat distr_view.sql
> DROP VIEW IF EXISTS xc_table_distribution;
> 
> 
> CREATE VIEW xc_table_distribution AS
> 
> SELECT pg_class.relname relation,
>        CASE
>          WHEN pclocatortype = 'H' THEN 'Hash'
>          WHEN pclocatortype = 'M' THEN 'Modulo'
>          WHEN pclocatortype = 'N' THEN 'Round Robin'
>          WHEN pclocatortype = 'R' THEN 'Replicate'
>          ELSE 'Unknown'
>        END AS distribution,
>        pg_attribute.attname attname
>     FROM pg_class, pgxc_class, pg_attribute
>     WHERE pg_class.oid = pgxc_class.pcrelid
>           and pg_class.oid = pg_attribute.attrelid
>           and pgxc_class.pcattnum = pg_attribute.attnum
>  UNION
> 
> SELECT pg_class.relname relation,
>        CASE
>          WHEN pclocatortype = 'H' THEN 'Hash'
>          WHEN pclocatortype = 'M' THEN 'Modulo'
>          WHEN pclocatortype = 'N' THEN 'Round Robin'
>          WHEN pclocatortype = 'R' THEN 'Replicate'
>          ELSE 'Unknown'
>        END AS distribution,
>        '- none -' attname
>    FROM pg_class, pgxc_class, pg_attribute
>    WHERE pg_class.oid = pgxc_class.pcrelid
>          and pg_class.oid = pg_attribute.attrelid
>          and pgxc_class.pcattnum = 0
>     ;
> 
> COMMENT ON VIEW xc_table_distribution IS
> 'View to show distribution/replication attribute of the given table.';
> 
> [koichi@linker:scripts]$
> ------
> 
> Info for pgbench tables are as follows:
> -----------
> koichi=# select * from xc_table_distribution
> koichi-# ;
>      relation     | distribution | attname
> ------------------+--------------+----------
>  t                | Hash         | a
>  pgbench_branches | Hash         | bid
>  y                | Modulo       | a
>  pgbench_tellers  | Hash         | bid
>  pgbench_accounts | Hash         | bid
>  x                | Round Robin  | - none -
>  pgbench_history  | Hash         | bid
>  s                | Replicate    | - none -
> (8 rows)
> 
> koichi=#
> ------
> 
> Hope it helps.
> 
> Regards;
> ----------
> Koichi Suzuki
> 
> 
> 2012/11/6 Tatsuo Ishii <is...@po...>:
>>> One suggestion.   Because set bid value is relatively small, it may be
>>> better to distribute tables using MODULO, not HASH.
>>
>> What is the distribution method when pgbench -k is used?
>> --
>> Tatsuo Ishii
>> SRA OSS, Inc. Japan
>> English: http://www.sraoss.co.jp/index_en.php
>> Japanese: http://www.sraoss.co.jp

The result has several noise.  Tables t, y, x, and s are all for my own test.

Sorry for inconvenience.
----------
Koichi Suzuki


2012/11/6 Koichi Suzuki <koi...@gm...>:
> pgxc_class has distribution definition of each table.    I'm using the
> following views as a handy tool:
>
> ----
> [koichi@linker:scripts]$ cat distr_view.sql
> DROP VIEW IF EXISTS xc_table_distribution;
>
>
> CREATE VIEW xc_table_distribution AS
>
> SELECT pg_class.relname relation,
>        CASE
>          WHEN pclocatortype = 'H' THEN 'Hash'
>          WHEN pclocatortype = 'M' THEN 'Modulo'
>          WHEN pclocatortype = 'N' THEN 'Round Robin'
>          WHEN pclocatortype = 'R' THEN 'Replicate'
>          ELSE 'Unknown'
>        END AS distribution,
>        pg_attribute.attname attname
>     FROM pg_class, pgxc_class, pg_attribute
>     WHERE pg_class.oid = pgxc_class.pcrelid
>           and pg_class.oid = pg_attribute.attrelid
>           and pgxc_class.pcattnum = pg_attribute.attnum
>  UNION
>
> SELECT pg_class.relname relation,
>        CASE
>          WHEN pclocatortype = 'H' THEN 'Hash'
>          WHEN pclocatortype = 'M' THEN 'Modulo'
>          WHEN pclocatortype = 'N' THEN 'Round Robin'
>          WHEN pclocatortype = 'R' THEN 'Replicate'
>          ELSE 'Unknown'
>        END AS distribution,
>        '- none -' attname
>    FROM pg_class, pgxc_class, pg_attribute
>    WHERE pg_class.oid = pgxc_class.pcrelid
>          and pg_class.oid = pg_attribute.attrelid
>          and pgxc_class.pcattnum = 0
>     ;
>
> COMMENT ON VIEW xc_table_distribution IS
> 'View to show distribution/replication attribute of the given table.';
>
> [koichi@linker:scripts]$
> ------
>
> Info for pgbench tables are as follows:
> -----------
> koichi=# select * from xc_table_distribution
> koichi-# ;
>      relation     | distribution | attname
> ------------------+--------------+----------
>  t                | Hash         | a
>  pgbench_branches | Hash         | bid
>  y                | Modulo       | a
>  pgbench_tellers  | Hash         | bid
>  pgbench_accounts | Hash         | bid
>  x                | Round Robin  | - none -
>  pgbench_history  | Hash         | bid
>  s                | Replicate    | - none -
> (8 rows)
>
> koichi=#
> ------
>
> Hope it helps.
>
> Regards;
> ----------
> Koichi Suzuki
>
>
> 2012/11/6 Tatsuo Ishii <is...@po...>:
>>> One suggestion.   Because set bid value is relatively small, it may be
>>> better to distribute tables using MODULO, not HASH.
>>
>> What is the distribution method when pgbench -k is used?
>> --
>> Tatsuo Ishii
>> SRA OSS, Inc. Japan
>> English: http://www.sraoss.co.jp/index_en.php
>> Japanese: http://www.sraoss.co.jp

pgxc_class has distribution definition of each table.    I'm using the
following views as a handy tool:

----
[koichi@linker:scripts]$ cat distr_view.sql
DROP VIEW IF EXISTS xc_table_distribution;


CREATE VIEW xc_table_distribution AS

SELECT pg_class.relname relation,
       CASE
         WHEN pclocatortype = 'H' THEN 'Hash'
         WHEN pclocatortype = 'M' THEN 'Modulo'
         WHEN pclocatortype = 'N' THEN 'Round Robin'
         WHEN pclocatortype = 'R' THEN 'Replicate'
         ELSE 'Unknown'
       END AS distribution,
       pg_attribute.attname attname
    FROM pg_class, pgxc_class, pg_attribute
    WHERE pg_class.oid = pgxc_class.pcrelid
          and pg_class.oid = pg_attribute.attrelid
          and pgxc_class.pcattnum = pg_attribute.attnum
 UNION

SELECT pg_class.relname relation,
       CASE
         WHEN pclocatortype = 'H' THEN 'Hash'
         WHEN pclocatortype = 'M' THEN 'Modulo'
         WHEN pclocatortype = 'N' THEN 'Round Robin'
         WHEN pclocatortype = 'R' THEN 'Replicate'
         ELSE 'Unknown'
       END AS distribution,
       '- none -' attname
   FROM pg_class, pgxc_class, pg_attribute
   WHERE pg_class.oid = pgxc_class.pcrelid
         and pg_class.oid = pg_attribute.attrelid
         and pgxc_class.pcattnum = 0
    ;

COMMENT ON VIEW xc_table_distribution IS
'View to show distribution/replication attribute of the given table.';

[koichi@linker:scripts]$
------

Info for pgbench tables are as follows:
-----------
koichi=# select * from xc_table_distribution
koichi-# ;
     relation     | distribution | attname
------------------+--------------+----------
 t                | Hash         | a
 pgbench_branches | Hash         | bid
 y                | Modulo       | a
 pgbench_tellers  | Hash         | bid
 pgbench_accounts | Hash         | bid
 x                | Round Robin  | - none -
 pgbench_history  | Hash         | bid
 s                | Replicate    | - none -
(8 rows)

koichi=#
------

Hope it helps.

Regards;
----------
Koichi Suzuki


2012/11/6 Tatsuo Ishii <is...@po...>:
>> One suggestion.   Because set bid value is relatively small, it may be
>> better to distribute tables using MODULO, not HASH.
>
> What is the distribution method when pgbench -k is used?
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp

Oh, I thought coordinator node knows everything about data node.

I did following:

execute direct on datanode1 'select * from pgxc_class as x join
pg_class as c on x.pcrelid = c.oid where c.relname =
''pgbench_accounts''';

on coordinator node and got 0 rows. Is that means pgbench_accounts
table is not distributed?

I did pgbench -k against coordinator node and I thought coordinator
automatically distributes data on each data node. Was this wrong
assumption?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

> Because pgxc_class and pg_class are both local to each node, oid is
> also local.   To query correctly, they should be issued using EXECUTE
> DIRECT statement.   Each EXECUTE DIRECT will return the result local
> to each node.
> 
> Regards;
> ----------
> Koichi Suzuki
> 
> 
> 2012/11/6 Tatsuo Ishii <is...@po...>:
>> I sent a query to coordinator node and got following result. Doesn't
>> this means table "pgbench_accounts" distributed?
>>
>> test=# select * from pgxc_class as x join pg_class as c on x.pcrelid = c.oid where c.relname = 'pgbench_accounts';
>> -[ RECORD 1 ]---+-----------------
>> pcrelid         | 16413
>> pclocatortype   | H
>> pcattnum        | 1
>> pchashalgorithm | 1
>> pchashbuckets   | 4096
>> nodeoids        | 16384 16385
>> relname         | pgbench_accounts
>> relnamespace    | 2200
>> reltype         | 16415
>> reloftype       | 0
>> relowner        | 10
>> relam           | 0
>> relfilenode     | 16419
>> reltablespace   | 0
>> relpages        | 0
>> reltuples       | 0
>> reltoastrelid   | 0
>> reltoastidxid   | 0
>> relhasindex     | t
>> relisshared     | f
>> relpersistence  | p
>> relkind         | r
>> relnatts        | 4
>> relchecks       | 0
>> relhasoids      | f
>> relhaspkey      | t
>> relhasrules     | f
>> relhastriggers  | f
>> relhassubclass  | f
>> relfrozenxid    | 78651
>> relacl          |
>> reloptions      | {fillfactor=100}
>>
>>> I tested with the current head (sorry) and found pg_statio_user_tables is available.
>>>
>>> Because this is not distributed tables (not distributed or replicated), query will return only local information of these tables.    Please use execute direct to query each node's statistics.
>>>
>>> Regards;
>>> ---
>>> Koichi Suzuki
>>>
>>> On Tue, 06 Nov 2012 15:02:37 +0900 (JST)
>>> Tatsuo Ishii <is...@po...> wrote:
>>>
>>>> Hi,
>>>>
>>>> It seems I cannot read pg_statio_user_tables from either coordinator or
>>>> data node. Is this a known limitation? I just would like to see how I
>>>> can confirm UPDATEs distributed among data nodes.
>>>> --
>>>> Tatsuo Ishii
>>>> SRA OSS, Inc. Japan
>>>> English: http://www.sraoss.co.jp/index_en.php
>>>> Japanese: http://www.sraoss.co.jp
>>>>
>>>> ------------------------------------------------------------------------------
>>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>>> Stay in control, update software, and manage PCs from one command center
>>>> Diagnose problems and improve visibility into emerging IT issues
>>>> Automate, monitor and manage. Do more in less time with Central
>>>> http://p.sf.net/sfu/logmein12331_d2d
>>>> _______________________________________________
>>>> Postgres-xc-general mailing list
>>>> Pos...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general

Because pgxc_class and pg_class are both local to each node, oid is
also local.   To query correctly, they should be issued using EXECUTE
DIRECT statement.   Each EXECUTE DIRECT will return the result local
to each node.

Regards;
----------
Koichi Suzuki


2012/11/6 Tatsuo Ishii <is...@po...>:
> I sent a query to coordinator node and got following result. Doesn't
> this means table "pgbench_accounts" distributed?
>
> test=# select * from pgxc_class as x join pg_class as c on x.pcrelid = c.oid where c.relname = 'pgbench_accounts';
> -[ RECORD 1 ]---+-----------------
> pcrelid         | 16413
> pclocatortype   | H
> pcattnum        | 1
> pchashalgorithm | 1
> pchashbuckets   | 4096
> nodeoids        | 16384 16385
> relname         | pgbench_accounts
> relnamespace    | 2200
> reltype         | 16415
> reloftype       | 0
> relowner        | 10
> relam           | 0
> relfilenode     | 16419
> reltablespace   | 0
> relpages        | 0
> reltuples       | 0
> reltoastrelid   | 0
> reltoastidxid   | 0
> relhasindex     | t
> relisshared     | f
> relpersistence  | p
> relkind         | r
> relnatts        | 4
> relchecks       | 0
> relhasoids      | f
> relhaspkey      | t
> relhasrules     | f
> relhastriggers  | f
> relhassubclass  | f
> relfrozenxid    | 78651
> relacl          |
> reloptions      | {fillfactor=100}
>
>> I tested with the current head (sorry) and found pg_statio_user_tables is available.
>>
>> Because this is not distributed tables (not distributed or replicated), query will return only local information of these tables.    Please use execute direct to query each node's statistics.
>>
>> Regards;
>> ---
>> Koichi Suzuki
>>
>> On Tue, 06 Nov 2012 15:02:37 +0900 (JST)
>> Tatsuo Ishii <is...@po...> wrote:
>>
>>> Hi,
>>>
>>> It seems I cannot read pg_statio_user_tables from either coordinator or
>>> data node. Is this a known limitation? I just would like to see how I
>>> can confirm UPDATEs distributed among data nodes.
>>> --
>>> Tatsuo Ishii
>>> SRA OSS, Inc. Japan
>>> English: http://www.sraoss.co.jp/index_en.php
>>> Japanese: http://www.sraoss.co.jp
>>>
>>> ------------------------------------------------------------------------------
>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>> Stay in control, update software, and manage PCs from one command center
>>> Diagnose problems and improve visibility into emerging IT issues
>>> Automate, monitor and manage. Do more in less time with Central
>>> http://p.sf.net/sfu/logmein12331_d2d
>>> _______________________________________________
>>> Postgres-xc-general mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general

I sent a query to coordinator node and got following result. Doesn't
this means table "pgbench_accounts" distributed?

test=# select * from pgxc_class as x join pg_class as c on x.pcrelid = c.oid where c.relname = 'pgbench_accounts';
-[ RECORD 1 ]---+-----------------
pcrelid         | 16413
pclocatortype   | H
pcattnum        | 1
pchashalgorithm | 1
pchashbuckets   | 4096
nodeoids        | 16384 16385
relname         | pgbench_accounts
relnamespace    | 2200
reltype         | 16415
reloftype       | 0
relowner        | 10
relam           | 0
relfilenode     | 16419
reltablespace   | 0
relpages        | 0
reltuples       | 0
reltoastrelid   | 0
reltoastidxid   | 0
relhasindex     | t
relisshared     | f
relpersistence  | p
relkind         | r
relnatts        | 4
relchecks       | 0
relhasoids      | f
relhaspkey      | t
relhasrules     | f
relhastriggers  | f
relhassubclass  | f
relfrozenxid    | 78651
relacl          | 
reloptions      | {fillfactor=100}

> I tested with the current head (sorry) and found pg_statio_user_tables is available.
> 
> Because this is not distributed tables (not distributed or replicated), query will return only local information of these tables.    Please use execute direct to query each node's statistics.
> 
> Regards;
> ---
> Koichi Suzuki
> 
> On Tue, 06 Nov 2012 15:02:37 +0900 (JST)
> Tatsuo Ishii <is...@po...> wrote:
> 
>> Hi,
>> 
>> It seems I cannot read pg_statio_user_tables from either coordinator or
>> data node. Is this a known limitation? I just would like to see how I
>> can confirm UPDATEs distributed among data nodes.
>> --
>> Tatsuo Ishii
>> SRA OSS, Inc. Japan
>> English: http://www.sraoss.co.jp/index_en.php
>> Japanese: http://www.sraoss.co.jp
>> 
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>> 

I tested with the current head (sorry) and found pg_statio_user_tables is available.

Because this is not distributed tables (not distributed or replicated), query will return only local information of these tables.    Please use execute direct to query each node's statistics.

Regards;
---
Koichi Suzuki

On Tue, 06 Nov 2012 15:02:37 +0900 (JST)
Tatsuo Ishii <is...@po...> wrote:

> Hi,
> 
> It seems I cannot read pg_statio_user_tables from either coordinator or
> data node. Is this a known limitation? I just would like to see how I
> can confirm UPDATEs distributed among data nodes.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp
> 
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
> 

Hi,

It seems I cannot read pg_statio_user_tables from either coordinator or
data node. Is this a known limitation? I just would like to see how I
can confirm UPDATEs distributed among data nodes.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

> One suggestion.   Because set bid value is relatively small, it may be
> better to distribute tables using MODULO, not HASH.

What is the distribution method when pgbench -k is used?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

> My fault. Sorry. (note the space between "--prefix=" and
> "/home/t-ishii...".
>
> BTW, I got "may be used uninitialized in this function" warnings while
> compiling. Are they safe?
>
Yes they are. The only reason why those things are not fixed yet is because
nobody took the time to seriously fix them all.
-- 
Michael Paquier
http://michael.otacoo.com

> On Tue, Nov 6, 2012 at 10:32 AM, Tatsuo Ishii <is...@po...> wrote:
> 
>> Hi,
>>
>> I tried this with Postgres-XC 1.0.1.
>>
>> [t-ishii@localhost pgxc]$ ./configure --prefix=
>> /home/t-ishii/work/Postgres-XC
>> configure: WARNING: you should use --build, --host, --target
>> configure: WARNING: invalid host type: /home/t-ishii/work/Postgres-XC
>> checking build system type... Invalid configuration
>> `/home/t-ishii/work/Postgres-XC': machine `/home/t-ishii/work/Postgres' not
>> recognized
>> configure: error: /bin/sh config/config.sub /home/t-ishii/work/Postgres-XC
>> failed
>>
>> It seems Postgres-XC's configure has a problem with prefix dir
>> including "-". Note that PostgreSQL 9.2.1. is fine with this kind of
>> directory name.
>>
> That's funny I can't reproduce it...

My fault. Sorry. (note the space between "--prefix=" and "/home/t-ishii...".

BTW, I got "may be used uninitialized in this function" warnings while
compiling. Are they safe?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

Oops. It appeared my fault. Sorry for noise.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

> Hi,
> 
> I tried this with Postgres-XC 1.0.1.
> 
> [t-ishii@localhost pgxc]$ ./configure --prefix= /home/t-ishii/work/Postgres-XC
> configure: WARNING: you should use --build, --host, --target
> configure: WARNING: invalid host type: /home/t-ishii/work/Postgres-XC
> checking build system type... Invalid configuration `/home/t-ishii/work/Postgres-XC': machine `/home/t-ishii/work/Postgres' not recognized
> configure: error: /bin/sh config/config.sub /home/t-ishii/work/Postgres-XC failed
> 
> It seems Postgres-XC's configure has a problem with prefix dir
> including "-". Note that PostgreSQL 9.2.1. is fine with this kind of
> directory name.
> 
> This is Linux 3.0.50 x86_64.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp
> 
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general

On Tue, Nov 6, 2012 at 10:32 AM, Tatsuo Ishii <is...@po...> wrote:

> Hi,
>
> I tried this with Postgres-XC 1.0.1.
>
> [t-ishii@localhost pgxc]$ ./configure --prefix=
> /home/t-ishii/work/Postgres-XC
> configure: WARNING: you should use --build, --host, --target
> configure: WARNING: invalid host type: /home/t-ishii/work/Postgres-XC
> checking build system type... Invalid configuration
> `/home/t-ishii/work/Postgres-XC': machine `/home/t-ishii/work/Postgres' not
> recognized
> configure: error: /bin/sh config/config.sub /home/t-ishii/work/Postgres-XC
> failed
>
> It seems Postgres-XC's configure has a problem with prefix dir
> including "-". Note that PostgreSQL 9.2.1. is fine with this kind of
> directory name.
>
That's funny I can't reproduce it...
-- 
Michael Paquier
http://michael.otacoo.com

I found a space after --prefix=

Removing this space runs configure without problem.

Regards;
----------
Koichi Suzuki


2012/11/6 Tatsuo Ishii <is...@po...>:
> Hi,
>
> I tried this with Postgres-XC 1.0.1.
>
> [t-ishii@localhost pgxc]$ ./configure --prefix= /home/t-ishii/work/Postgres-XC
> configure: WARNING: you should use --build, --host, --target
> configure: WARNING: invalid host type: /home/t-ishii/work/Postgres-XC
> checking build system type... Invalid configuration `/home/t-ishii/work/Postgres-XC': machine `/home/t-ishii/work/Postgres' not recognized
> configure: error: /bin/sh config/config.sub /home/t-ishii/work/Postgres-XC failed
>
> It seems Postgres-XC's configure has a problem with prefix dir
> including "-". Note that PostgreSQL 9.2.1. is fine with this kind of
> directory name.
>
> This is Linux 3.0.50 x86_64.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general

One suggestion.   Because set bid value is relatively small, it may be
better to distribute tables using MODULO, not HASH.

Regards;
----------
Koichi Suzuki


2012/11/6 Michael Paquier <mic...@gm...>:
>
>
> On Tue, Nov 6, 2012 at 10:05 AM, Tatsuo Ishii <is...@po...> wrote:
>>
>> Hi,
>>
>> PostgreSQL Enterprise Consortium is planning to do a benchmark against
>> Postges-XC. If we would use standard pgbench workload(pgbench default,
>> -N, -S), what is a recommended portioning plan for pgbench_accounts?
>
> If you want to show up the scalability, I recommend that you use pgbench
> with option -k for initialization and launching, which is an option that has
> been added in the pgbench version of XC available in its source code. This
> allows to to a benchmark test by using bid as a distribution key so this
> minimizes the amount of 2PC done when write operations involve several nodes
> in a transaction.
> $ pgbench --help
> Initialization options:
>   -k           distribute by primary key branch id - bid
> Benchmarking options:
>   -k           query with default key and additional key branch id (bid)
>
> Depending on your cluster structure, I would also recommend you also to use
> PREFERRED node with ALTER NODE (ALTER NODE nodename WITH (PREFERRED)) for
> example with the Datanode that is on the same server as a Coordinator if you
> use a structure of 1 Coordinator and 1 Datanode per server. This also
> reduces the network load by having replicated table read being done on the
> preferred node in priority. This is especially better if the node is local
> of course.
>
>
>>
>>
>> Any suggestions will be appreciated.
>> --
>> Tatsuo Ishii
>> SRA OSS, Inc. Japan
>> English: http://www.sraoss.co.jp/index_en.php
>> Japanese: http://www.sraoss.co.jp
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
>
>
>
> --
> Michael Paquier
> http://michael.otacoo.com
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>

Hi,

I tried this with Postgres-XC 1.0.1.

[t-ishii@localhost pgxc]$ ./configure --prefix= /home/t-ishii/work/Postgres-XC
configure: WARNING: you should use --build, --host, --target
configure: WARNING: invalid host type: /home/t-ishii/work/Postgres-XC
checking build system type... Invalid configuration `/home/t-ishii/work/Postgres-XC': machine `/home/t-ishii/work/Postgres' not recognized
configure: error: /bin/sh config/config.sub /home/t-ishii/work/Postgres-XC failed

It seems Postgres-XC's configure has a problem with prefix dir
including "-". Note that PostgreSQL 9.2.1. is fine with this kind of
directory name.

This is Linux 3.0.50 x86_64.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

On Tue, Nov 6, 2012 at 10:05 AM, Tatsuo Ishii <is...@po...> wrote:

> Hi,
>
> PostgreSQL Enterprise Consortium is planning to do a benchmark against
> Postges-XC. If we would use standard pgbench workload(pgbench default,
> -N, -S), what is a recommended portioning plan for pgbench_accounts?
>
If you want to show up the scalability, I recommend that you use pgbench
with option -k for initialization and launching, which is an option that
has been added in the pgbench version of XC available in its source code.
This allows to to a benchmark test by using bid as a distribution key so
this minimizes the amount of 2PC done when write operations involve several
nodes in a transaction.
$ pgbench --help
Initialization options:
  -k           distribute by primary key branch id - bid
Benchmarking options:
  -k           query with default key and additional key branch id (bid)

Depending on your cluster structure, I would also recommend you also to use
PREFERRED node with ALTER NODE (ALTER NODE nodename WITH (PREFERRED)) for
example with the Datanode that is on the same server as a Coordinator if
you use a structure of 1 Coordinator and 1 Datanode per server. This also
reduces the network load by having replicated table read being done on the
preferred node in priority. This is especially better if the node is local
of course.



>
> Any suggestions will be appreciated.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>



-- 
Michael Paquier
http://michael.otacoo.com

Hi,

PostgreSQL Enterprise Consortium is planning to do a benchmark against
Postges-XC. If we would use standard pgbench workload(pgbench default,
-N, -S), what is a recommended portioning plan for pgbench_accounts?

Any suggestions will be appreciated.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

Does anybody has performance data for DRBD with PostgreSQL?   The
following reports that the throughput will become almost half.

http://archives.postgresql.org/pgsql-performance/2007-09/msg00118.php

The article is posted about five years ago, though.

Regards;
----------
Koichi Suzuki


2012/11/6 Vladimir Stavrinov <vst...@gm...>:
> On Mon, Nov 05, 2012 at 07:22:54PM +0300, Vladimir Stavrinov wrote:
>
>> solution is alliance of drbd + pacemaker + corosync. It is  very
>
> Forgot to add in this team ipvs.
>
>
> *****************************
> ###  Vladimir Stavrinov
> ###  vst...@gm...
> *****************************
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general

On Mon, Nov 05, 2012 at 07:22:54PM +0300, Vladimir Stavrinov wrote:

> solution is alliance of drbd + pacemaker + corosync. It is  very

Forgot to add in this team ipvs.


*****************************
###  Vladimir Stavrinov
###  vst...@gm...
*****************************

On Tue, Oct 30, 2012 at 10:02 PM, Roger Mayes <rog...@gm...> wrote:

> Odd that their list publishes our email addresses, and if I hit "reply" (in
> gmail), it goes to the person who made the post rather than to the list.

Click arrow on the right of "Reply" button, then click "Reply all". Or
copy/past list address into CC: field.

> gmail is more-or-less commercial software, isn't it?  Lol.

No matter commercial or not. More important is open source criteria.

> It seems like our conversation has gone a bit afield of the list's topic,
> anyway.

We continue discussion about HA for XC.

> So have you found any way to do get write scalability and high availability?

I've already wrote here about this. I think at this time the best
solution is alliance of drbd + pacemaker + corosync. It is  very
effective, reliable and rather simple setup for duplicating every
node. I have such architecture running lot of vz boxes. But it is no
matter what services are there running. The difference is only
resource agent, i.e. start/stop script. BTW among others (most of them
are web, application and database servers) there are postgresql
running inside those vz boxes without any problems.