Menu
▾
▴
postgres-xc-general — General info and messages
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
(19) |
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(12) |
Feb
(1) |
Mar
(4) |
Apr
(4) |
May
(32) |
Jun
(12) |
Jul
(11) |
Aug
(1) |
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(10) |
| 2012 |
Jan
(11) |
Feb
(1) |
Mar
(3) |
Apr
(25) |
May
(53) |
Jun
(38) |
Jul
(103) |
Aug
(54) |
Sep
(31) |
Oct
(66) |
Nov
(77) |
Dec
(20) |
| 2013 |
Jan
(91) |
Feb
(86) |
Mar
(103) |
Apr
(107) |
May
(25) |
Jun
(37) |
Jul
(17) |
Aug
(59) |
Sep
(38) |
Oct
(78) |
Nov
(29) |
Dec
(15) |
| 2014 |
Jan
(23) |
Feb
(82) |
Mar
(118) |
Apr
(101) |
May
(103) |
Jun
(45) |
Jul
(6) |
Aug
(10) |
Sep
|
Oct
(32) |
Nov
|
Dec
(9) |
| 2015 |
Jan
(3) |
Feb
(5) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(9) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Nikhil S. <ni...@st...> - 2013-03-26 18:16:47
|
> prod-xc-coord01 > postgres=# select * from pgxc_node; > node_name | node_type | node_port | node_host | nodeis_primary | nodeis_preferred | node_id > -----------+-----------+-----------+--------------+----------------+------------------+------------ > coord1 | C | 5432 | localhost | f | f | 1885696643 > datanode1 | D | 6543 | localhost | t | t | 888802358 > datanode2 | D | 6543 | 10.101.51.38 | f | f | -905831925 > > prod-xc-coord02 > postgres=# select * from pgxc_node; > node_name | node_type | node_port | node_host | nodeis_primary | nodeis_preferred | node_id > -----------+-----------+-----------+--------------+----------------+------------------+------------- > coord2 | C | 5432 | localhost | f | f | -1197102633 > datanode1 | D | 6543 | 10.245.114.8 | t | f | 888802358 > datanode2 | D | 6543 | localhost | f | t | -905831925 > > after that setup I was able to create tabases from the both coordinator nodes, but each coordinator does not see the database created by the other coordinator. > You need to add coord1 metadata on coord2 node and vice versa as well. Regards, Nikhils -- StormDB - http://www.stormdb.com The Database Cloud |
|
From: seikath <se...@gm...> - 2013-03-26 14:31:18
|
Hello Ashutosh, My initial setup was datanode1 as primary on all coordinators. But the database created on coordinator1 was not visible by coordinator2 even it was populated at the both datanodes. So I tested with one primary datanode on one coordinator, hoping the GTM will know that and will distribute the info. Anyway, these are my firsts steps with XC, so I might did some simple config error .. I want to use the coordinators as a entry points for loadbalanced external SQL requests Kind regards, Ivan On 03/26/2013 03:21 PM, Ashutosh Bapat wrote: > > > On Tue, Mar 26, 2013 at 7:46 PM, seikath <se...@gm... <mailto:se...@gm...>> wrote: > > Hello all, > > I have an XC setup of 4 AWS instances: > > ============================= > instance: prod-xc-coord1 > > coordinator config at prod-xc-coord1 > listen_addresses = '*' > port = 5432 > max_connections = 100 > shared_buffers = 120MB > max_prepared_transactions = 100 > datestyle = 'iso, mdy' > lc_messages = 'en_US.UTF-8' > lc_monetary = 'en_US.UTF-8' > lc_numeric = 'en_US.UTF-8' > lc_time = 'en_US.UTF-8' > default_text_search_config = 'pg_catalog.english' > pooler_port = 6667 > min_pool_size = 1 > max_pool_size = 100 > max_coordinators = 16 > max_datanodes = 16 > gtm_host = '10.196.154.85' > gtm_port = 6543 > pgxc_node_name = 'coord1' > enforce_two_phase_commit = on > enable_fast_query_shipping = on > enable_remotejoin = on > enable_remotegroup = on > > datanode config at prod-xc-coord1 > listen_addresses = '*' > port = 6543 > max_connections = 100 > shared_buffers = 320MB > max_prepared_transactions = 100 > datestyle = 'iso, mdy' > lc_messages = 'en_US.UTF-8' > lc_monetary = 'en_US.UTF-8' > lc_numeric = 'en_US.UTF-8' > lc_time = 'en_US.UTF-8' > default_text_search_config = 'pg_catalog.english' > max_coordinators = 16 > max_datanodes = 16 > gtm_host = '10.196.154.85' > gtm_port = 6543 > pgxc_node_name = 'datanode1' > enforce_two_phase_commit = on > enable_fast_query_shipping = on > enable_remotejoin = on > enable_remotegroup = on > > > ============================= > instance : prod-xc-coord2 > > coordinator config at prod-xc-coord2 > listen_addresses = '*' > port = 5432 > max_connections = 100 > superuser_reserved_connections = 3 > shared_buffers = 120MB > max_prepared_transactions = 100 > datestyle = 'iso, mdy' > lc_messages = 'en_US.UTF-8' > lc_monetary = 'en_US.UTF-8' > lc_numeric = 'en_US.UTF-8' > lc_time = 'en_US.UTF-8' > default_text_search_config = 'pg_catalog.english' > pooler_port = 6667 > min_pool_size = 1 > max_pool_size = 100 > max_coordinators = 16 > max_datanodes = 16 > gtm_host = '10.196.154.85' > gtm_port = 6543 > pgxc_node_name = 'coord2' > enforce_two_phase_commit = on > enable_fast_query_shipping = on > enable_remotejoin = on > enable_remotegroup = on > > datanode config at prod-xc-coord2 > listen_addresses = '*' > port = 6543 > max_connections = 100 > shared_buffers = 320MB > max_prepared_transactions = 100 > datestyle = 'iso, mdy' > lc_messages = 'en_US.UTF-8' > lc_monetary = 'en_US.UTF-8' > lc_numeric = 'en_US.UTF-8' > lc_time = 'en_US.UTF-8' > default_text_search_config = 'pg_catalog.english' > max_coordinators = 16 > max_datanodes = 16 > gtm_host = '10.196.154.85' > gtm_port = 6543 > pgxc_node_name = 'datanode2' > enforce_two_phase_commit = on > enable_fast_query_shipping = on > enable_remotejoin = on > enable_remotegroup = on > > ============================= > instance prod-xc-gtm-proxy : IP 10.196.154.85 > > proxy config: > nodename = 'one' > listen_addresses = '*' > port = 6543 > gtm_host = '10.244.158.120' > gtm_port = 5432 > > ============================= > instance prod-xc-gtm : IP 10.244.158.120 > gtm config > nodename = 'one' > listen_addresses = '*' > port = 5432 > > > ============================= > > the pg_hba,conf of both coordinator and data nodes at both prod-xc-coord1 and prod-xc-coord2 > allows the other node to connect: > ================================================= > pg_hba,conf at prod-xc-coord01 IP 10.245.114.8 > local all all trust > host all all 127.0.0.1/32 <http://127.0.0.1/32> trust > host all all ::1/128 trust > host all all 10.101.51.38/32 <http://10.101.51.38/32> trust > > pg_hba,conf at prod-xc-coord02 IP 10.101.51.38 > local all all trust > host all all 127.0.0.1/32 <http://127.0.0.1/32> trust > host all all ::1/128 trust > host all all 10.245.114.8/32 <http://10.245.114.8/32> trust > > the connectivity is tested and confirmed. > ================================================= > > initial nodes setup: > prod-xc-coord01 > postgres=# select * from pgxc_node; > node_name | node_type | node_port | node_host | nodeis_primary | nodeis_preferred | node_id > -----------+-----------+-----------+--------------+----------------+------------------+------------ > coord1 | C | 5432 | localhost | f | f | 1885696643 > datanode1 | D | 6543 | localhost | t | t | 888802358 > datanode2 | D | 6543 | 10.101.51.38 | f | f | -905831925 > > prod-xc-coord02 > postgres=# select * from pgxc_node; > node_name | node_type | node_port | node_host | nodeis_primary | nodeis_preferred | node_id > -----------+-----------+-----------+--------------+----------------+------------------+------------- > coord2 | C | 5432 | localhost | f | f | -1197102633 > datanode1 | D | 6543 | 10.245.114.8 | t | f | 888802358 > datanode2 | D | 6543 | localhost | f | t | -905831925 > > after that setup I was able to create tabases from the both coordinator nodes, but each coordinator does not see the database created by the other > coordinator. > > > > then tested and the node setup with one only primary node: > prod-xc-coord02 > postgres=# alter node datanode1 with (type = 'datanode', host = '10.245.114.8', port = 6543, primary=false,preferred=false); > ALTER NODE > postgres=# select pgxc_pool_reload(); > pgxc_pool_reload > ------------------ > t > (1 row) > postgres=# select * from pgxc_node; > node_name | node_type | node_port | node_host | nodeis_primary | nodeis_preferred | node_id > -----------+-----------+-----------+--------------+----------------+------------------+------------- > coord2 | C | 5432 | localhost | f | f | -1197102633 > datanode2 | D | 6543 | localhost | f | t | -905831925 > datanode1 | D | 6543 | 10.245.114.8 | f | f | 888802358 > (3 rows) > > the result is the same. > > I know I am missing something simple as a config or open port, but at the moment I cant figure out whats missing in the setup. > > > What are you trying to do here? You have set primary node for datanode1 to false, which is what the query result displays. Can you please elaborate what's > going wrong? > > In general our plan is to use loadbalancer in frond of several instances hosting one coordinator and one datanode. > > I apologize for the ugly paste, but I am not sure if that mail list support html formatting. > > Kind regards, > > Ivan > > > > > > > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... <mailto:Pos...@li...> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Enterprise Postgres Company |
|
From: Ashutosh B. <ash...@en...> - 2013-03-26 14:21:13
|
On Tue, Mar 26, 2013 at 7:46 PM, seikath <se...@gm...> wrote: > Hello all, > > I have an XC setup of 4 AWS instances: > > ============================= > instance: prod-xc-coord1 > > coordinator config at prod-xc-coord1 > listen_addresses = '*' > port = 5432 > max_connections = 100 > shared_buffers = 120MB > max_prepared_transactions = 100 > datestyle = 'iso, mdy' > lc_messages = 'en_US.UTF-8' > lc_monetary = 'en_US.UTF-8' > lc_numeric = 'en_US.UTF-8' > lc_time = 'en_US.UTF-8' > default_text_search_config = 'pg_catalog.english' > pooler_port = 6667 > min_pool_size = 1 > max_pool_size = 100 > max_coordinators = 16 > max_datanodes = 16 > gtm_host = '10.196.154.85' > gtm_port = 6543 > pgxc_node_name = 'coord1' > enforce_two_phase_commit = on > enable_fast_query_shipping = on > enable_remotejoin = on > enable_remotegroup = on > > datanode config at prod-xc-coord1 > listen_addresses = '*' > port = 6543 > max_connections = 100 > shared_buffers = 320MB > max_prepared_transactions = 100 > datestyle = 'iso, mdy' > lc_messages = 'en_US.UTF-8' > lc_monetary = 'en_US.UTF-8' > lc_numeric = 'en_US.UTF-8' > lc_time = 'en_US.UTF-8' > default_text_search_config = 'pg_catalog.english' > max_coordinators = 16 > max_datanodes = 16 > gtm_host = '10.196.154.85' > gtm_port = 6543 > pgxc_node_name = 'datanode1' > enforce_two_phase_commit = on > enable_fast_query_shipping = on > enable_remotejoin = on > enable_remotegroup = on > > > ============================= > instance : prod-xc-coord2 > > coordinator config at prod-xc-coord2 > listen_addresses = '*' > port = 5432 > max_connections = 100 > superuser_reserved_connections = 3 > shared_buffers = 120MB > max_prepared_transactions = 100 > datestyle = 'iso, mdy' > lc_messages = 'en_US.UTF-8' > lc_monetary = 'en_US.UTF-8' > lc_numeric = 'en_US.UTF-8' > lc_time = 'en_US.UTF-8' > default_text_search_config = 'pg_catalog.english' > pooler_port = 6667 > min_pool_size = 1 > max_pool_size = 100 > max_coordinators = 16 > max_datanodes = 16 > gtm_host = '10.196.154.85' > gtm_port = 6543 > pgxc_node_name = 'coord2' > enforce_two_phase_commit = on > enable_fast_query_shipping = on > enable_remotejoin = on > enable_remotegroup = on > > datanode config at prod-xc-coord2 > listen_addresses = '*' > port = 6543 > max_connections = 100 > shared_buffers = 320MB > max_prepared_transactions = 100 > datestyle = 'iso, mdy' > lc_messages = 'en_US.UTF-8' > lc_monetary = 'en_US.UTF-8' > lc_numeric = 'en_US.UTF-8' > lc_time = 'en_US.UTF-8' > default_text_search_config = 'pg_catalog.english' > max_coordinators = 16 > max_datanodes = 16 > gtm_host = '10.196.154.85' > gtm_port = 6543 > pgxc_node_name = 'datanode2' > enforce_two_phase_commit = on > enable_fast_query_shipping = on > enable_remotejoin = on > enable_remotegroup = on > > ============================= > instance prod-xc-gtm-proxy : IP 10.196.154.85 > > proxy config: > nodename = 'one' > listen_addresses = '*' > port = 6543 > gtm_host = '10.244.158.120' > gtm_port = 5432 > > ============================= > instance prod-xc-gtm : IP 10.244.158.120 > gtm config > nodename = 'one' > listen_addresses = '*' > port = 5432 > > > ============================= > > the pg_hba,conf of both coordinator and data nodes at both prod-xc-coord1 > and prod-xc-coord2 > allows the other node to connect: > ================================================= > pg_hba,conf at prod-xc-coord01 IP 10.245.114.8 > local all all trust > host all all 127.0.0.1/32 trust > host all all ::1/128 trust > host all all 10.101.51.38/32 trust > > pg_hba,conf at prod-xc-coord02 IP 10.101.51.38 > local all all trust > host all all 127.0.0.1/32 trust > host all all ::1/128 trust > host all all 10.245.114.8/32 trust > > the connectivity is tested and confirmed. > ================================================= > > initial nodes setup: > prod-xc-coord01 > postgres=# select * from pgxc_node; > node_name | node_type | node_port | node_host | nodeis_primary | > nodeis_preferred | node_id > > -----------+-----------+-----------+--------------+----------------+------------------+------------ > coord1 | C | 5432 | localhost | f | f > | 1885696643 > datanode1 | D | 6543 | localhost | t | t > | 888802358 > datanode2 | D | 6543 | 10.101.51.38 | f | f > | -905831925 > > prod-xc-coord02 > postgres=# select * from pgxc_node; > node_name | node_type | node_port | node_host | nodeis_primary | > nodeis_preferred | node_id > > -----------+-----------+-----------+--------------+----------------+------------------+------------- > coord2 | C | 5432 | localhost | f | f > | -1197102633 > datanode1 | D | 6543 | 10.245.114.8 | t | f > | 888802358 > datanode2 | D | 6543 | localhost | f | t > | -905831925 > > after that setup I was able to create tabases from the both coordinator > nodes, but each coordinator does not see the database created by the other > coordinator. > > > > then tested and the node setup with one only primary node: > prod-xc-coord02 > postgres=# alter node datanode1 with (type = 'datanode', host = > '10.245.114.8', port = 6543, primary=false,preferred=false); > ALTER NODE > postgres=# select pgxc_pool_reload(); > pgxc_pool_reload > ------------------ > t > (1 row) > postgres=# select * from pgxc_node; > node_name | node_type | node_port | node_host | nodeis_primary | > nodeis_preferred | node_id > > -----------+-----------+-----------+--------------+----------------+------------------+------------- > coord2 | C | 5432 | localhost | f | f > | -1197102633 > datanode2 | D | 6543 | localhost | f | t > | -905831925 > datanode1 | D | 6543 | 10.245.114.8 | f | f > | 888802358 > (3 rows) > > the result is the same. > > I know I am missing something simple as a config or open port, but at the > moment I cant figure out whats missing in the setup. > > What are you trying to do here? You have set primary node for datanode1 to false, which is what the query result displays. Can you please elaborate what's going wrong? > In general our plan is to use loadbalancer in frond of several instances > hosting one coordinator and one datanode. > > I apologize for the ugly paste, but I am not sure if that mail list > support html formatting. > > Kind regards, > > Ivan > > > > > > > > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Enterprise Postgres Company |
|
From: seikath <se...@gm...> - 2013-03-26 14:16:53
|
Hello all, I have an XC setup of 4 AWS instances: ============================= instance: prod-xc-coord1 coordinator config at prod-xc-coord1 listen_addresses = '*' port = 5432 max_connections = 100 shared_buffers = 120MB max_prepared_transactions = 100 datestyle = 'iso, mdy' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' pooler_port = 6667 min_pool_size = 1 max_pool_size = 100 max_coordinators = 16 max_datanodes = 16 gtm_host = '10.196.154.85' gtm_port = 6543 pgxc_node_name = 'coord1' enforce_two_phase_commit = on enable_fast_query_shipping = on enable_remotejoin = on enable_remotegroup = on datanode config at prod-xc-coord1 listen_addresses = '*' port = 6543 max_connections = 100 shared_buffers = 320MB max_prepared_transactions = 100 datestyle = 'iso, mdy' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' max_coordinators = 16 max_datanodes = 16 gtm_host = '10.196.154.85' gtm_port = 6543 pgxc_node_name = 'datanode1' enforce_two_phase_commit = on enable_fast_query_shipping = on enable_remotejoin = on enable_remotegroup = on ============================= instance : prod-xc-coord2 coordinator config at prod-xc-coord2 listen_addresses = '*' port = 5432 max_connections = 100 superuser_reserved_connections = 3 shared_buffers = 120MB max_prepared_transactions = 100 datestyle = 'iso, mdy' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' pooler_port = 6667 min_pool_size = 1 max_pool_size = 100 max_coordinators = 16 max_datanodes = 16 gtm_host = '10.196.154.85' gtm_port = 6543 pgxc_node_name = 'coord2' enforce_two_phase_commit = on enable_fast_query_shipping = on enable_remotejoin = on enable_remotegroup = on datanode config at prod-xc-coord2 listen_addresses = '*' port = 6543 max_connections = 100 shared_buffers = 320MB max_prepared_transactions = 100 datestyle = 'iso, mdy' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' max_coordinators = 16 max_datanodes = 16 gtm_host = '10.196.154.85' gtm_port = 6543 pgxc_node_name = 'datanode2' enforce_two_phase_commit = on enable_fast_query_shipping = on enable_remotejoin = on enable_remotegroup = on ============================= instance prod-xc-gtm-proxy : IP 10.196.154.85 proxy config: nodename = 'one' listen_addresses = '*' port = 6543 gtm_host = '10.244.158.120' gtm_port = 5432 ============================= instance prod-xc-gtm : IP 10.244.158.120 gtm config nodename = 'one' listen_addresses = '*' port = 5432 ============================= the pg_hba,conf of both coordinator and data nodes at both prod-xc-coord1 and prod-xc-coord2 allows the other node to connect: ================================================= pg_hba,conf at prod-xc-coord01 IP 10.245.114.8 local all all trust host all all 127.0.0.1/32 trust host all all ::1/128 trust host all all 10.101.51.38/32 trust pg_hba,conf at prod-xc-coord02 IP 10.101.51.38 local all all trust host all all 127.0.0.1/32 trust host all all ::1/128 trust host all all 10.245.114.8/32 trust the connectivity is tested and confirmed. ================================================= initial nodes setup: prod-xc-coord01 postgres=# select * from pgxc_node; node_name | node_type | node_port | node_host | nodeis_primary | nodeis_preferred | node_id -----------+-----------+-----------+--------------+----------------+------------------+------------ coord1 | C | 5432 | localhost | f | f | 1885696643 datanode1 | D | 6543 | localhost | t | t | 888802358 datanode2 | D | 6543 | 10.101.51.38 | f | f | -905831925 prod-xc-coord02 postgres=# select * from pgxc_node; node_name | node_type | node_port | node_host | nodeis_primary | nodeis_preferred | node_id -----------+-----------+-----------+--------------+----------------+------------------+------------- coord2 | C | 5432 | localhost | f | f | -1197102633 datanode1 | D | 6543 | 10.245.114.8 | t | f | 888802358 datanode2 | D | 6543 | localhost | f | t | -905831925 after that setup I was able to create tabases from the both coordinator nodes, but each coordinator does not see the database created by the other coordinator. then tested and the node setup with one only primary node: prod-xc-coord02 postgres=# alter node datanode1 with (type = 'datanode', host = '10.245.114.8', port = 6543, primary=false,preferred=false); ALTER NODE postgres=# select pgxc_pool_reload(); pgxc_pool_reload ------------------ t (1 row) postgres=# select * from pgxc_node; node_name | node_type | node_port | node_host | nodeis_primary | nodeis_preferred | node_id -----------+-----------+-----------+--------------+----------------+------------------+------------- coord2 | C | 5432 | localhost | f | f | -1197102633 datanode2 | D | 6543 | localhost | f | t | -905831925 datanode1 | D | 6543 | 10.245.114.8 | f | f | 888802358 (3 rows) the result is the same. I know I am missing something simple as a config or open port, but at the moment I cant figure out whats missing in the setup. In general our plan is to use loadbalancer in frond of several instances hosting one coordinator and one datanode. I apologize for the ugly paste, but I am not sure if that mail list support html formatting. Kind regards, Ivan |
|
From: Ashutosh B. <ash...@en...> - 2013-03-25 03:54:48
|
Hi Arni, If you have development resources, we will welcome your patches for improvements in this area. On Fri, Mar 22, 2013 at 7:17 PM, Arni Sumarlidason < Arn...@md...> wrote: > Thank you for your responses and support! We will find a work around!**** > > ** ** > > Best,**** > > ** ** > > *From:* Ashutosh Bapat [mailto:ash...@en...] > *Sent:* Friday, March 22, 2013 10:56 AM > > *To:* Arni Sumarlidason > *Cc:* Koichi Suzuki; pos...@li... > *Subject:* Re: [Postgres-xc-general] Planner join logic**** > > ** ** > > We haven't yet worked to optimize any case of inheritance. It's not that > it can't be done, it's just there are more pressing issues to be solved.** > ** > > On Fri, Mar 22, 2013 at 6:25 PM, Arni Sumarlidason < > Arn...@md...> wrote:**** > > Is this in the case of joins, or will we have the same issue with a flat > table?**** > > Please advise.**** > > **** > > *From:* Ashutosh Bapat [mailto:ash...@en...<ash...@en...>] > > *Sent:* Friday, March 22, 2013 1:14 AM**** > > > *To:* Arni Sumarlidason > *Cc:* Koichi Suzuki; pos...@li... > *Subject:* Re: [Postgres-xc-general] Planner join logic**** > > **** > > In case children table, we need an Append node covering scans on each > table. We haven't optimized planner for the case of inheritance yet.**** > > **** > > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Enterprise Postgres Company**** > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Enterprise Postgres Company |
|
From: Arni S. <Arn...@md...> - 2013-03-22 15:17:56
|
Thank you for your responses and support! We will find a work around! Best, From: Ashutosh Bapat [mailto:ash...@en...] Sent: Friday, March 22, 2013 10:56 AM To: Arni Sumarlidason Cc: Koichi Suzuki; pos...@li... Subject: Re: [Postgres-xc-general] Planner join logic We haven't yet worked to optimize any case of inheritance. It's not that it can't be done, it's just there are more pressing issues to be solved. On Fri, Mar 22, 2013 at 6:25 PM, Arni Sumarlidason <Arn...@md...<mailto:Arn...@md...>> wrote: Is this in the case of joins, or will we have the same issue with a flat table? Please advise. From: Ashutosh Bapat [mailto:ash...@en...] Sent: Friday, March 22, 2013 1:14 AM To: Arni Sumarlidason Cc: Koichi Suzuki; pos...@li...<mailto:pos...@li...> Subject: Re: [Postgres-xc-general] Planner join logic In case children table, we need an Append node covering scans on each table. We haven't optimized planner for the case of inheritance yet. -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Enterprise Postgres Company |
|
From: Ashutosh B. <ash...@en...> - 2013-03-22 14:56:35
|
We haven't yet worked to optimize any case of inheritance. It's not that it can't be done, it's just there are more pressing issues to be solved. On Fri, Mar 22, 2013 at 6:25 PM, Arni Sumarlidason < Arn...@md...> wrote: > Is this in the case of joins, or will we have the same issue with a flat > table?**** > > Please advise.**** > > ** ** > > *From:* Ashutosh Bapat [mailto:ash...@en...<ash...@en...>] > > *Sent:* Friday, March 22, 2013 1:14 AM > > *To:* Arni Sumarlidason > *Cc:* Koichi Suzuki; pos...@li... > *Subject:* Re: [Postgres-xc-general] Planner join logic**** > > ** ** > > In case children table, we need an Append node covering scans on each > table. We haven't optimized planner for the case of inheritance yet.**** > > ** ** > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Enterprise Postgres Company |
|
From: Arni S. <Arn...@md...> - 2013-03-22 14:25:20
|
Is this in the case of joins, or will we have the same issue with a flat table? Please advise. From: Ashutosh Bapat [mailto:ash...@en...] Sent: Friday, March 22, 2013 1:14 AM To: Arni Sumarlidason Cc: Koichi Suzuki; pos...@li...<mailto:pos...@li...> Subject: Re: [Postgres-xc-general] Planner join logic In case children table, we need an Append node covering scans on each table. We haven't optimized planner for the case of inheritance yet. |
|
From: Arni S. <Arn...@md...> - 2013-03-22 14:24:26
|
Is this in the case of joins, or will we have the same issue with a flat table?
Please advise.
From: Ashutosh Bapat [mailto:ash...@en...]
Sent: Friday, March 22, 2013 1:14 AM
To: Arni Sumarlidason
Cc: Koichi Suzuki; pos...@li...
Subject: Re: [Postgres-xc-general] Planner join logic
In case children table, we need an Append node covering scans on each table. We haven't optimized planner for the case of inheritance yet.
On Fri, Mar 22, 2013 at 9:10 AM, Arni Sumarlidason <Arn...@md...<mailto:Arn...@md...>> wrote:
Here we go,
Table "public.table"
Column | Type | Modifiers | Storage | Stats target | Description
---------------------------+--------------------------+-----------+----------+--------------+-------------
id | bigint | not null | plain | |
seq | integer | not null | plain | |
text | character varying(256) | | extended | |
date_updated | timestamp with time zone | | plain | |
Indexes:
"table_pkey" PRIMARY KEY, btree (id, seq)
"idx_table_dateupdated" btree (date_updated)
Child tables: table_1202,
table_1203,
table_1204,
table_1205,
table_1206,
table_1207,
table_1208,
table_1209,
table_1210,
table_1211,
table_20121111,
table_20121118,
table_20121125,
table_20121202,
table_20121209,
table_20121216,
table_20121223,
table_20121230,
table_20130106,
table_20130113,
table_20130120,
table_20130127,
table_20130203,
table_20130210,
table_20130217,
table_20130224,
table_20130303,
table_20130310,
table_20130317,
table_20130324,
table_20130331,
table_20130407,
table_20130414,
table_20130421,
table_20130428
Has OIDs: no
Table "public.table_2"
Column | Type | Modifiers | Storage | Stats target | Description
------------------------------------+--------------------------+-----------+----------+--------------+-------------
id | bigint | not null | plain | |
text_updated | character varying(1024) | | extended | |
date_updated | timestamp with time zone | | plain | |
seq | integer | not null | plain | |
Indexes:
"table_2_pkey" PRIMARY KEY, btree (id, seq)
"idx_table2_dateupdated" btree (date_updated)
"idx_table2_id" btree (id)
Child tables: table_2_120806,
table_2_120813,
table_2_120820,
table_2_120827,
table_2_120903,
table_2_120910,
table_2_120917,
table_2_120924,
table_2_121001,
table_2_121008,
table_2_121015,
table_2_121022,
table_2_121029,
table_2_121105,
table_2_121112,
table_2_121119,
table_2_121126,
table_2_121203,
table_2_121210,
table_2_121217,
table_2_121224,
table_2_121231,
table_2_130107,
table_2_130114,
table_2_130121,
table_2_130128,
table_2_130204,
table_2_130211,
table_2_130218,
table_2_130225,
table_2_130304,
table_2_130311,
table_2_130318,
table_2_130325,
table_2_130401,
table_2_130408,
table_2_130415,
table_2_130422,
table_2_130429,
table_2_130506,
table_2_130513,
table_2_130520,
table_2_130527,
table_2_130603,
table_2_130610,
table_2_130617,
table_2_130624,
table_2_130701,
table_2_130708,
table_2_130715,
table_2_130722,
table_2_130729,
table_2_130805,
table_2_130812,
table_2_130819,
table_2_130826,
table_2_130902,
table_2_130909,
table_2_130916,
table_2_130923,
table_2_130930,
table_2_131007,
table_2_131014,
table_2_131021,
table_2_131028,
table_2_131104,
table_2_131111,
table_2_131118,
table_2_131125,
table_2_131202,
table_2_131209,
table_2_131216,
table_2_131223,
table_2_131230,
table_2_140106,
table_2_140113,
table_2_140120,
table_2_140127,
table_2_140203,
table_2_140210,
table_2_140217,
table_2_140224,
table_2_140303,
table_2_140310,
table_2_140317,
table_2_140324,
table_2_140331,
table_2_140407,
table_2_140414,
table_2_140421,
table_2_140428,
table_2_140505,
table_2_140512,
table_2_140519,
table_2_140526,
table_2_140602,
table_2_140609,
table_2_140616,
table_2_140623,
table_2_140630,
table_2_140707,
table_2_140714,
table_2_140721,
table_2_140728,
table_2_140804,
table_2_140811,
table_2_140818,
table_2_140825,
table_2_140901,
table_2_140908,
table_2_140915,
table_2_140922,
table_2_140929,
table_2_141006,
table_2_141013,
table_2_141020,
table_2_141027,
table_2_141103,
table_2_141110,
table_2_141117,
table_2_141124,
table_2_141201,
table_2_141208,
table_2_141215,
table_2_141222,
table_2_141229,
table_2_150105,
table_2_150112,
table_2_150119,
table_2_150126
Has OIDs: no
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
|
|
From: Ashutosh B. <ash...@en...> - 2013-03-22 05:14:00
|
In case children table, we need an Append node covering scans on each table. We haven't optimized planner for the case of inheritance yet. On Fri, Mar 22, 2013 at 9:10 AM, Arni Sumarlidason < Arn...@md...> wrote: > Here we go, **** > > ** ** > > ** ** > > Table "public.table"**** > > Column | Type | Modifiers | > Storage | Stats target | Description**** > > > ---------------------------+--------------------------+-----------+----------+--------------+------------- > **** > > id | bigint | not null | > plain | |**** > > seq | integer | not null | > plain | |**** > > text | character varying(256) | | > extended | |**** > > date_updated | timestamp with time zone | | plain > | |**** > > Indexes:**** > > "table_pkey" PRIMARY KEY, btree (id, seq)**** > > "idx_table_dateupdated" btree (date_updated)**** > > Child tables: table_1202,**** > > table_1203,**** > > table_1204,**** > > table_1205,**** > > table_1206,**** > > table_1207,**** > > table_1208,**** > > table_1209,**** > > table_1210,**** > > table_1211,**** > > table_20121111,**** > > table_20121118,**** > > table_20121125,**** > > table_20121202,**** > > table_20121209,**** > > table_20121216,**** > > table_20121223,**** > > table_20121230,**** > > table_20130106,**** > > table_20130113,**** > > table_20130120,**** > > table_20130127,**** > > table_20130203,**** > > table_20130210,**** > > table_20130217,**** > > table_20130224,**** > > table_20130303,**** > > table_20130310,**** > > table_20130317,**** > > table_20130324,**** > > table_20130331,**** > > table_20130407,**** > > table_20130414,**** > > table_20130421,**** > > table_20130428**** > > Has OIDs: no**** > > ** ** > > ** ** > > ** ** > > Table "public.table_2"**** > > Column | Type | Modifiers > | Storage | Stats target | Description**** > > > ------------------------------------+--------------------------+-----------+----------+--------------+------------- > **** > > id | bigint | not null > | plain | |**** > > text_updated | character varying(1024) | | > extended | |**** > > date_updated | timestamp with time zone | | > plain | |**** > > seq | integer | not null > | plain | |**** > > Indexes:**** > > "table_2_pkey" PRIMARY KEY, btree (id, seq)**** > > "idx_table2_dateupdated" btree (date_updated)**** > > "idx_table2_id" btree (id)**** > > Child tables: table_2_120806,**** > > table_2_120813,**** > > table_2_120820,**** > > table_2_120827,**** > > table_2_120903,**** > > table_2_120910,**** > > table_2_120917,**** > > table_2_120924,**** > > table_2_121001,**** > > table_2_121008,**** > > table_2_121015,**** > > table_2_121022,**** > > table_2_121029,**** > > table_2_121105,**** > > table_2_121112,**** > > table_2_121119,**** > > table_2_121126,**** > > table_2_121203,**** > > table_2_121210,**** > > table_2_121217,**** > > table_2_121224,**** > > table_2_121231,**** > > table_2_130107,**** > > table_2_130114,**** > > table_2_130121,**** > > table_2_130128,**** > > table_2_130204,**** > > table_2_130211,**** > > table_2_130218,**** > > table_2_130225,**** > > table_2_130304,**** > > table_2_130311,**** > > table_2_130318,**** > > table_2_130325,**** > > table_2_130401,**** > > table_2_130408,**** > > table_2_130415,**** > > table_2_130422,**** > > table_2_130429,**** > > table_2_130506,**** > > table_2_130513,**** > > table_2_130520,**** > > table_2_130527,**** > > table_2_130603,**** > > table_2_130610,**** > > table_2_130617,**** > > table_2_130624,**** > > table_2_130701,**** > > table_2_130708,**** > > table_2_130715,**** > > table_2_130722,**** > > table_2_130729,**** > > table_2_130805,**** > > table_2_130812,**** > > table_2_130819,**** > > table_2_130826,**** > > table_2_130902,**** > > table_2_130909,**** > > table_2_130916,**** > > table_2_130923,**** > > table_2_130930,**** > > table_2_131007,**** > > table_2_131014,**** > > table_2_131021,**** > > table_2_131028,**** > > table_2_131104,**** > > table_2_131111,**** > > table_2_131118,**** > > table_2_131125,**** > > table_2_131202,**** > > table_2_131209,**** > > table_2_131216,**** > > table_2_131223,**** > > table_2_131230,**** > > table_2_140106,**** > > table_2_140113,**** > > table_2_140120,**** > > table_2_140127,**** > > table_2_140203,**** > > table_2_140210,**** > > table_2_140217,**** > > table_2_140224,**** > > table_2_140303,**** > > table_2_140310,**** > > table_2_140317,**** > > table_2_140324,**** > > table_2_140331,**** > > table_2_140407,**** > > table_2_140414,**** > > table_2_140421,**** > > table_2_140428,**** > > table_2_140505,**** > > table_2_140512,**** > > table_2_140519,**** > > table_2_140526,**** > > table_2_140602,**** > > table_2_140609,**** > > table_2_140616,**** > > table_2_140623,**** > > table_2_140630,**** > > table_2_140707,**** > > table_2_140714,**** > > table_2_140721,**** > > table_2_140728,**** > > table_2_140804,**** > > table_2_140811,**** > > table_2_140818,**** > > table_2_140825,**** > > table_2_140901,**** > > table_2_140908,**** > > table_2_140915,**** > > table_2_140922,**** > > table_2_140929,**** > > table_2_141006,**** > > table_2_141013,**** > > table_2_141020,**** > > table_2_141027,**** > > table_2_141103,**** > > table_2_141110,**** > > table_2_141117,**** > > table_2_141124,**** > > table_2_141201,**** > > table_2_141208,**** > > table_2_141215,**** > > table_2_141222,**** > > table_2_141229,**** > > table_2_150105,**** > > table_2_150112,**** > > table_2_150119,**** > > table_2_150126**** > > Has OIDs: no**** > > ** ** > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Enterprise Postgres Company |
|
From: Arni S. <Arn...@md...> - 2013-03-22 05:10:50
|
Here we go,
Table "public.table"
Column | Type | Modifiers | Storage | Stats target | Description
---------------------------+--------------------------+-----------+----------+--------------+-------------
id | bigint | not null | plain | |
seq | integer | not null | plain | |
text | character varying(256) | | extended | |
date_updated | timestamp with time zone | | plain | |
Indexes:
"table_pkey" PRIMARY KEY, btree (id, seq)
"idx_table_dateupdated" btree (date_updated)
Child tables: table_1202,
table_1203,
table_1204,
table_1205,
table_1206,
table_1207,
table_1208,
table_1209,
table_1210,
table_1211,
table_20121111,
table_20121118,
table_20121125,
table_20121202,
table_20121209,
table_20121216,
table_20121223,
table_20121230,
table_20130106,
table_20130113,
table_20130120,
table_20130127,
table_20130203,
table_20130210,
table_20130217,
table_20130224,
table_20130303,
table_20130310,
table_20130317,
table_20130324,
table_20130331,
table_20130407,
table_20130414,
table_20130421,
table_20130428
Has OIDs: no
Table "public.table_2"
Column | Type | Modifiers | Storage | Stats target | Description
------------------------------------+--------------------------+-----------+----------+--------------+-------------
id | bigint | not null | plain | |
text_updated | character varying(1024) | | extended | |
date_updated | timestamp with time zone | | plain | |
seq | integer | not null | plain | |
Indexes:
"table_2_pkey" PRIMARY KEY, btree (id, seq)
"idx_table2_dateupdated" btree (date_updated)
"idx_table2_id" btree (id)
Child tables: table_2_120806,
table_2_120813,
table_2_120820,
table_2_120827,
table_2_120903,
table_2_120910,
table_2_120917,
table_2_120924,
table_2_121001,
table_2_121008,
table_2_121015,
table_2_121022,
table_2_121029,
table_2_121105,
table_2_121112,
table_2_121119,
table_2_121126,
table_2_121203,
table_2_121210,
table_2_121217,
table_2_121224,
table_2_121231,
table_2_130107,
table_2_130114,
table_2_130121,
table_2_130128,
table_2_130204,
table_2_130211,
table_2_130218,
table_2_130225,
table_2_130304,
table_2_130311,
table_2_130318,
table_2_130325,
table_2_130401,
table_2_130408,
table_2_130415,
table_2_130422,
table_2_130429,
table_2_130506,
table_2_130513,
table_2_130520,
table_2_130527,
table_2_130603,
table_2_130610,
table_2_130617,
table_2_130624,
table_2_130701,
table_2_130708,
table_2_130715,
table_2_130722,
table_2_130729,
table_2_130805,
table_2_130812,
table_2_130819,
table_2_130826,
table_2_130902,
table_2_130909,
table_2_130916,
table_2_130923,
table_2_130930,
table_2_131007,
table_2_131014,
table_2_131021,
table_2_131028,
table_2_131104,
table_2_131111,
table_2_131118,
table_2_131125,
table_2_131202,
table_2_131209,
table_2_131216,
table_2_131223,
table_2_131230,
table_2_140106,
table_2_140113,
table_2_140120,
table_2_140127,
table_2_140203,
table_2_140210,
table_2_140217,
table_2_140224,
table_2_140303,
table_2_140310,
table_2_140317,
table_2_140324,
table_2_140331,
table_2_140407,
table_2_140414,
table_2_140421,
table_2_140428,
table_2_140505,
table_2_140512,
table_2_140519,
table_2_140526,
table_2_140602,
table_2_140609,
table_2_140616,
table_2_140623,
table_2_140630,
table_2_140707,
table_2_140714,
table_2_140721,
table_2_140728,
table_2_140804,
table_2_140811,
table_2_140818,
table_2_140825,
table_2_140901,
table_2_140908,
table_2_140915,
table_2_140922,
table_2_140929,
table_2_141006,
table_2_141013,
table_2_141020,
table_2_141027,
table_2_141103,
table_2_141110,
table_2_141117,
table_2_141124,
table_2_141201,
table_2_141208,
table_2_141215,
table_2_141222,
table_2_141229,
table_2_150105,
table_2_150112,
table_2_150119,
table_2_150126
Has OIDs: no
|
|
From: Arni S. <Arn...@md...> - 2013-03-22 05:09:02
|
Table "public.table"
Column | Type | Modifiers | Storage | Stats target | Description
---------------------------+--------------------------+-----------+----------+--------------+-------------
id | bigint | not null | plain | |
seq | integer | not null | plain | |
text | character varying(256) | | extended | |
date_updated | timestamp with time zone | | plain | |
Indexes:
"table_pkey" PRIMARY KEY, btree (id, seq)
"idx_table_dateupdated" btree (date_updated)
Child tables: table_1202,
table_1203,
table_1204,
table_1205,
table_1206,
table_1207,
table_1208,
table_1209,
table_1210,
table_1211,
table_20121111,
table_20121118,
table_20121125,
table_20121202,
table_20121209,
table_20121216,
table_20121223,
table_20121230,
table_20130106,
table_20130113,
table_20130120,
table_20130127,
table_20130203,
table_20130210,
table_20130217,
table_20130224,
table_20130303,
table_20130310,
table_20130317,
table_20130324,
table_20130331,
table_20130407,
table_20130414,
table_20130421,
table_20130428
Has OIDs: no
Table "public.table_2"
Column | Type | Modifiers | Storage | Stats target | Description
------------------------------------+--------------------------+-----------+----------+--------------+-------------
id | bigint | not null | plain | |
text_updated | character varying(1024) | | extended | |
date_updated | timestamp with time zone | | plain | |
seq | integer | not null | plain | |
Indexes:
"table_2_pkey" PRIMARY KEY, btree (id, seq)
"idx_table2_dateupdated" btree (date_updated)
"idx_table2_id" btree (id)
Child tables: table_2_120806,
table_2_120813,
table_2_120820,
table_2_120827,
table_2_120903,
table_2_120910,
table_2_120917,
table_2_120924,
table_2_121001,
table_2_121008,
table_2_121015,
table_2_121022,
table_2_121029,
table_2_121105,
table_2_121112,
table_2_121119,
table_2_121126,
table_2_121203,
table_2_121210,
table_2_121217,
table_2_121224,
table_2_121231,
table_2_130107,
table_2_130114,
table_2_130121,
table_2_130128,
table_2_130204,
table_2_130211,
table_2_130218,
table_2_130225,
table_2_130304,
table_2_130311,
table_2_130318,
table_2_130325,
table_2_130401,
table_2_130408,
table_2_130415,
table_2_130422,
table_2_130429,
table_2_130506,
table_2_130513,
table_2_130520,
table_2_130527,
table_2_130603,
table_2_130610,
table_2_130617,
table_2_130624,
table_2_130701,
table_2_130708,
table_2_130715,
table_2_130722,
table_2_130729,
table_2_130805,
table_2_130812,
table_2_130819,
table_2_130826,
table_2_130902,
table_2_130909,
table_2_130916,
table_2_130923,
table_2_130930,
table_2_131007,
table_2_131014,
table_2_131021,
table_2_131028,
table_2_131104,
table_2_131111,
table_2_131118,
table_2_131125,
table_2_131202,
table_2_131209,
table_2_131216,
table_2_131223,
table_2_131230,
table_2_140106,
table_2_140113,
table_2_140120,
table_2_140127,
table_2_140203,
table_2_140210,
table_2_140217,
table_2_140224,
table_2_140303,
table_2_140310,
table_2_140317,
table_2_140324,
table_2_140331,
table_2_140407,
table_2_140414,
table_2_140421,
table_2_140428,
table_2_140505,
table_2_140512,
table_2_140519,
table_2_140526,
table_2_140602,
table_2_140609,
table_2_140616,
table_2_140623,
table_2_140630,
table_2_140707,
table_2_140714,
table_2_140721,
table_2_140728,
table_2_140804,
table_2_140811,
table_2_140818,
table_2_140825,
table_2_140901,
table_2_140908,
table_2_140915,
table_2_140922,
table_2_140929,
table_2_141006,
table_2_141013,
table_2_141020,
table_2_141027,
table_2_141103,
table_2_141110,
table_2_141117,
table_2_141124,
table_2_141201,
table_2_141208,
table_2_141215,
table_2_141222,
table_2_141229,
table_2_150105,
table_2_150112,
table_2_150119,
table_2_150126
Has OIDs: no
From: Ashutosh Bapat [mailto:ash...@en...]
Sent: Friday, March 22, 2013 12:57 AM
To: Arni Sumarlidason
Cc: Koichi Suzuki; pos...@li...
Subject: Re: [Postgres-xc-general] Planner join logic
Hi Arni,
By any chance, you have children inheriting from table1 and table2? Can you please send \d+ output on these tables?
On Fri, Mar 22, 2013 at 8:49 AM, Arni Sumarlidason <Arn...@md...<mailto:Arn...@md...>> wrote:
Hello Mr. Bapat,
I modified the output a little, but only the fields selected,
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash Join (cost=1.64..5.35 rows=236 width=10726)
Output: t.id<https://console.mxlogic.com/redir/?hP3z1EVud79EVdLzCm6kjhOqejo0evigdTVBOZXTLuZPtPuQ9JPHgDN3lJC2LxfUHhBjQ27bCQTQnTPqbbz9EVjujpKroodwLQzh0qmMJmAOcvEn3X5OfM-eDCBQQg1o_og-9Ew4qOwq83WApmdPYfDwedECTzrb38UsqenT3pYEg_QCosxO0>, t.seq, t.text, t.date_updated
Hash Cond: (t.id<https://console.mxlogic.com/redir/?2eosod7bNEVd79JYsOMOyqejhOr01PWi1K_cKnLuZXTKrKrSxdKtq4-8qJIMlY9_5qcGuwgVsSC-y--rhpspd7arOrdPr31I5-Aq83iS5GQChzZ2UvoKh-7NQYQKCy0b7X27Nd40zmk3h0vkzaNKvxYY1NJcSYrpop73zhO-UrarRR5I62> = l.id<https://console.mxlogic.com/redir/?4sMUMqenzhOqejrUVBxB4QsCzAS03fWi1K_cKnLuZXTKrKrSxdKtq4-8qJIMlY9_5qcGuwgVsSC-y--rhpspd7arOrdPr31I5-Aq83iS5GQChzZ2UvoKh-7NQYQKCy0b7X27Nd40zmk3h0vkzaNKvxYY1NJASYrpop73zhO-Ur3j24>)
-> Append (cost=0.00..0.00 rows=36000 width=5638)
-> Data Node Scan on table "_REMOTE_TABLE_QUERY_" (cost=0.00..0.00 rows=1000 width=5638)
Output: t.id<https://console.mxlogic.com/redir/?hP3z1EVud79EVdLzCm6kjhOqejo0evigdTVBOZXTLuZPtPuQ9JPHgDN3lJC2LxfUHhBjQ27bCQTQnTPqbbz9EVjujpKroodwLQzh0qmMJmAOcvEn3X5OfM-eDCBQQg1o_og-9Ew4qOwq83WApmdPYfDwedI6Tzrb38UsqenT3ueCo8533qnKK>, t.seq, t.text, t.date_updated
Node/s: datanode01d, datanode02d, datanode03d, datanode04d, datanode05d, datanode06d, datanode07d, datanode08d, datanode09d, datanode10d, datanode11d, datanode12d, datanode13d, datanode14d, datanode15d, datanode16d, datanode17d, datanode18d, datanode19d, datanode20d
Remote query: SELECT id, seq, text, date_updated FROM ONLY table t WHERE true
+ 10-20 similar
-> Hash (cost=0.00..0.00 rows=131000 width=5088)
Output: l.id<https://console.mxlogic.com/redir/?4sMUMqenzhOqejrUVBxB4QsCzAS03fWi1K_cKnLuZXTKrKrSxdKtq4-8qJIMlY9_5qcGuwgVsSC-y--rhpspd7arOrdPr31I5-Aq83iS5GQChzZ2UvoKh-7NQYQKCy0b7X27Nd40zmk3h0vkzaNKvxYY1NJYSYrpop73zhO-Urs1e07wQU>, l.date_updated, l.seq, l.text
-> Append (cost=0.00..0.00 rows=131000 width=5088)
-> Data Node Scan on table_2 "_REMOTE_TABLE_QUERY_" (cost=0.00..0.00 rows=1000 width=5088)
Output: l.id<https://console.mxlogic.com/redir/?4sMUMqenzhOqejrUVBxB4QsCzAS03fWi1K_cKnLuZXTKrKrSxdKtq4-8qJIMlY9_5qcGuwgVsSC-y--rhpspd7arOrdPr31I5-Aq83iS5GQChzZ2UvoKh-7NQYQKCy0b7X27Nd40zmk3h0vkzaNKvxYY1NJMSYrpop73zhO-UrrbcP>, l.date_updated, l.seq, l.text
Node/s: datanode01d, datanode02d, datanode03d, datanode04d, datanode05d, datanode06d, datanode07d, datanode08d, datanode09d, datanode10d, datanode11d, datanode12d, datanode13d, datanode14d, datanode15d, datanode16d, datanode17d, datanode18d, datanode19d, datanode20d
Remote query: SELECT id, date_updated, seq, text FROM ONLY table_2 l WHERE ((date_updated >= '2012-12-15 00:00:00-05'::timestamp with time zone) AND (date_updated < '2013-01-01 00:00:00-05'::timestamp with time zone))
+ 30-50 Similar
Thank you for your time,
From: Ashutosh Bapat [mailto:ash...@en...<mailto:ash...@en...>]
Sent: Friday, March 22, 2013 12:28 AM
To: Arni Sumarlidason
Cc: Koichi Suzuki; pos...@li...<mailto:pos...@li...>
Subject: Re: [Postgres-xc-general] Planner join logic
Hi Arni,
Can you please send an explain verbose output of this query?
On Thu, Mar 21, 2013 at 5:57 PM, Arni Sumarlidason <Arn...@md...<mailto:Arn...@md...>> wrote:
As always, thank you for your responses, appreciate it!
We are using trunk from around Feb. 18th.
Here are some tables that replicate the issue,
create table table1(
id bigint,
seq integer,
text data(256),
created_at timestamp with time zone,
PRIMARY KEY(id, seq)) DISTRIBUTE BY HASH(id);
create table table2(
id bigint,
seq integer,
text data_complex(256),
update_time timestamp with time zone,
PRIMARY KEY(id, seq)) DISTRIBUTE BY HASH(id);
Select * from table1 t1, table2 t2 where t2.update_time >= '2012-12-15' and t2.update_time < '2013-01-01' and t2.id<https://console.mxlogic.com/redir/?2eosod7bNEVd79JYsOMOyqejhOr01PjWi1K_cKnLuZXTKrKrSxdKtq4-8qJIMlY9_5qcGuwgVsSYYyCrhpspd7arz3XxJxwS2_id41Fr2Rqj8N-xsfIn8_3UWuqnjh05zZx3UCy0hHa1EwfGhBoTfM-u0USyrjdIIczxNEVvsdVuuN3I-tei91>=t1.id<https://console.mxlogic.com/redir/?zC763hOYqejhOrv7cIcECzAQsCM0sQuAwrLPbBXTLuZXCXCZEjrDmxfy6Hrc5v2vNmzaDE4endLf8FCQmn6jhOCUM-UroodwLQzh0qmMJmAOcvEn3X5OfM-eDCBQQg1o_og-9Ew4qOwq83WApmdPYfDwedFCQPrb38UsqenT3qiXMGWXj>
Thank you,
Arni
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
|
|
From: Ashutosh B. <ash...@en...> - 2013-03-22 04:57:16
|
Hi Arni, By any chance, you have children inheriting from table1 and table2? Can you please send \d+ output on these tables? On Fri, Mar 22, 2013 at 8:49 AM, Arni Sumarlidason < Arn...@md...> wrote: > Hello Mr. Bapat,**** > > ** ** > > I modified the output a little, but only the fields selected,**** > > > QUERY > PLAN > > **** > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > **** > > Hash Join (cost=1.64..5.35 rows=236 width=10726)**** > > Output: t.id, t.seq, t.text, t.date_updated**** > > Hash Cond: (t.id = l.id)**** > > -> Append (cost=0.00..0.00 rows=36000 width=5638)**** > > -> Data Node Scan on table "_REMOTE_TABLE_QUERY_" > (cost=0.00..0.00 rows=1000 width=5638)**** > > Output: t.id, t.seq, t.text, t.date_updated**** > > Node/s: datanode01d, datanode02d, datanode03d, datanode04d, > datanode05d, datanode06d, datanode07d, datanode08d, datanode09d, > datanode10d, datanode11d, datanode12d, datanode13d, datanode14d, > datanode15d, datanode16d, datanode17d, datanode18d, datanode19d, datanode20d > **** > > Remote query: SELECT id, seq, text, date_updated FROM ONLY > table t WHERE true**** > > ** ** > > + 10-20 similar**** > > **** > > -> Hash (cost=0.00..0.00 rows=131000 width=5088)**** > > Output: l.id, l.date_updated, l.seq, l.text**** > > -> Append (cost=0.00..0.00 rows=131000 width=5088)**** > > -> Data Node Scan on table_2 "_REMOTE_TABLE_QUERY_" > (cost=0.00..0.00 rows=1000 width=5088)**** > > Output: l.id, l.date_updated, l.seq, l.text**** > > Node/s: datanode01d, datanode02d, datanode03d, > datanode04d, datanode05d, datanode06d, datanode07d, datanode08d, > datanode09d, datanode10d, datanode11d, datanode12d, datanode13d, > datanode14d, datanode15d, datanode16d, datanode17d, datanode18d, > datanode19d, datanode20d**** > > Remote query: SELECT id, date_updated, seq, text FROM > ONLY table_2 l WHERE ((date_updated >= '2012-12-15 00:00:00-05'::timestamp > with time zone) AND (date_updated < '2013-01-01 00:00:00-05'::timestamp > with time zone))**** > > ** ** > > + 30-50 Similar**** > > ** ** > > Thank you for your time,**** > > ** ** > > *From:* Ashutosh Bapat [mailto:ash...@en...] > *Sent:* Friday, March 22, 2013 12:28 AM > *To:* Arni Sumarlidason > *Cc:* Koichi Suzuki; pos...@li... > *Subject:* Re: [Postgres-xc-general] Planner join logic**** > > ** ** > > Hi Arni, > Can you please send an explain verbose output of this query?**** > > On Thu, Mar 21, 2013 at 5:57 PM, Arni Sumarlidason < > Arn...@md...> wrote:**** > > As always, thank you for your responses, appreciate it! **** > > **** > > We are using trunk from around Feb. 18th.**** > > **** > > Here are some tables that replicate the issue,**** > > create table table1(**** > > id bigint,**** > > seq integer,**** > > text data(256),**** > > created_at timestamp with time zone,**** > > PRIMARY KEY(id, seq)) DISTRIBUTE BY HASH(id);**** > > **** > > create table table2(**** > > id bigint,**** > > seq integer,**** > > text data_complex(256),**** > > update_time timestamp with time zone,**** > > PRIMARY KEY(id, seq)) DISTRIBUTE BY HASH(id);**** > > **** > > Select * from table1 t1, table2 t2 where t2.update_time >= ‘2012-12-15’ > and t2.update_time < ‘2013-01-01’ and t2.id<https://console.mxlogic.com/redir/?2eosod7bNEVd79JYsOMOyqejhOr01PjWi1K_cKnLuZXTKrKrSxdKtq4-8qJIMlY9_5qcGuwgVsSYYyCrhpspd7arz3XxJxwS2_id41Fr2Rqj8N-xsfIn8_3UWuqnjh05zZx3UCy0hHa1EwfGhBoTfM-u0USyrjdIIczxNEVvsdVuuN3I-tei91> > =t1.id<https://console.mxlogic.com/redir/?zC763hOYqejhOrv7cIcECzAQsCM0sQuAwrLPbBXTLuZXCXCZEjrDmxfy6Hrc5v2vNmzaDE4endLf8FCQmn6jhOCUM-UroodwLQzh0qmMJmAOcvEn3X5OfM-eDCBQQg1o_og-9Ew4qOwq83WApmdPYfDwedFCQPrb38UsqenT3qiXMGWXj> > **** > > **** > > Thank you,**** > > Arni**** > > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Enterprise Postgres Company**** > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Enterprise Postgres Company |
|
From: Arni S. <Arn...@md...> - 2013-03-22 04:49:18
|
Hello Mr. Bapat,
I modified the output a little, but only the fields selected,
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash Join (cost=1.64..5.35 rows=236 width=10726)
Output: t.id, t.seq, t.text, t.date_updated
Hash Cond: (t.id = l.id)
-> Append (cost=0.00..0.00 rows=36000 width=5638)
-> Data Node Scan on table "_REMOTE_TABLE_QUERY_" (cost=0.00..0.00 rows=1000 width=5638)
Output: t.id, t.seq, t.text, t.date_updated
Node/s: datanode01d, datanode02d, datanode03d, datanode04d, datanode05d, datanode06d, datanode07d, datanode08d, datanode09d, datanode10d, datanode11d, datanode12d, datanode13d, datanode14d, datanode15d, datanode16d, datanode17d, datanode18d, datanode19d, datanode20d
Remote query: SELECT id, seq, text, date_updated FROM ONLY table t WHERE true
+ 10-20 similar
-> Hash (cost=0.00..0.00 rows=131000 width=5088)
Output: l.id, l.date_updated, l.seq, l.text
-> Append (cost=0.00..0.00 rows=131000 width=5088)
-> Data Node Scan on table_2 "_REMOTE_TABLE_QUERY_" (cost=0.00..0.00 rows=1000 width=5088)
Output: l.id, l.date_updated, l.seq, l.text
Node/s: datanode01d, datanode02d, datanode03d, datanode04d, datanode05d, datanode06d, datanode07d, datanode08d, datanode09d, datanode10d, datanode11d, datanode12d, datanode13d, datanode14d, datanode15d, datanode16d, datanode17d, datanode18d, datanode19d, datanode20d
Remote query: SELECT id, date_updated, seq, text FROM ONLY table_2 l WHERE ((date_updated >= '2012-12-15 00:00:00-05'::timestamp with time zone) AND (date_updated < '2013-01-01 00:00:00-05'::timestamp with time zone))
+ 30-50 Similar
Thank you for your time,
From: Ashutosh Bapat [mailto:ash...@en...]
Sent: Friday, March 22, 2013 12:28 AM
To: Arni Sumarlidason
Cc: Koichi Suzuki; pos...@li...
Subject: Re: [Postgres-xc-general] Planner join logic
Hi Arni,
Can you please send an explain verbose output of this query?
On Thu, Mar 21, 2013 at 5:57 PM, Arni Sumarlidason <Arn...@md...<mailto:Arn...@md...>> wrote:
As always, thank you for your responses, appreciate it!
We are using trunk from around Feb. 18th.
Here are some tables that replicate the issue,
create table table1(
id bigint,
seq integer,
text data(256),
created_at timestamp with time zone,
PRIMARY KEY(id, seq)) DISTRIBUTE BY HASH(id);
create table table2(
id bigint,
seq integer,
text data_complex(256),
update_time timestamp with time zone,
PRIMARY KEY(id, seq)) DISTRIBUTE BY HASH(id);
Select * from table1 t1, table2 t2 where t2.update_time >= '2012-12-15' and t2.update_time < '2013-01-01' and t2.id<https://console.mxlogic.com/redir/?2eosod7bNEVd79JYsOMOyqejhOr01PjWi1K_cKnLuZXTKrKrSxdKtq4-8qJIMlY9_5qcGuwgVsSYYyCrhpspd7arz3XxJxwS2_id41Fr2Rqj8N-xsfIn8_3UWuqnjh05zZx3UCy0hHa1EwfGhBoTfM-u0USyrjdIIczxNEVvsdVuuN3I-tei91>=t1.id<https://console.mxlogic.com/redir/?zC763hOYqejhOrv7cIcECzAQsCM0sQuAwrLPbBXTLuZXCXCZEjrDmxfy6Hrc5v2vNmzaDE4endLf8FCQmn6jhOCUM-UroodwLQzh0qmMJmAOcvEn3X5OfM-eDCBQQg1o_og-9Ew4qOwq83WApmdPYfDwedFCQPrb38UsqenT3qiXMGWXj>
Thank you,
Arni
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
|
|
From: Ashutosh B. <ash...@en...> - 2013-03-22 04:27:42
|
Hi Arni, Can you please send an explain verbose output of this query? On Thu, Mar 21, 2013 at 5:57 PM, Arni Sumarlidason < Arn...@md...> wrote: > As always, thank you for your responses, appreciate it! **** > > ** ** > > We are using trunk from around Feb. 18th.**** > > ** ** > > Here are some tables that replicate the issue,**** > > create table table1(**** > > id bigint,**** > > seq integer,**** > > text data(256),**** > > created_at timestamp with time zone,**** > > PRIMARY KEY(id, seq)) DISTRIBUTE BY HASH(id);**** > > ** ** > > create table table2(**** > > id bigint,**** > > seq integer,**** > > text data_complex(256),**** > > update_time timestamp with time zone,**** > > PRIMARY KEY(id, seq)) DISTRIBUTE BY HASH(id);**** > > ** ** > > Select * from table1 t1, table2 t2 where t2.update_time >= ‘2012-12-15’ > and t2.update_time < ‘2013-01-01’ and t2.id=t1.id**** > > ** ** > > Thank you,**** > > Arni**** > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Enterprise Postgres Company |
|
From: Koichi S. <koi...@gm...> - 2013-03-21 07:52:05
|
You can try pgxc_pool_reload() and pgxc_pool_check() as found at http://postgres-xc.sourceforge.net/docs/1_0_2/functions-admin.html Another means is CLEAN CONNECTION statement, http://postgres-xc.sourceforge.net/docs/1_0_2/sql-cleanconnection.html Regards; ---------- Koichi Suzuki 2013/3/21 Chris Brown <cb...@in...>: > Hi all, > > I have previously run successful tests with 2 datanodes and I'm trying to > run the same test with 3 datanodes. I am able to create/drop tables and > insert/select rows from all 3 coordinators. The test runs if I point it > at a single coordinator (doesn't matter which one) and set the number of > clients to 32. Each datanode box is running > datanode+coordinator(master)+gtm_proxy and gtm is running on a 4th box. > > I have upped max_pool_size on the coordinator and max_connections on the > datanode to 400. I haven't upped max_prepared_transactions however I > don't think any of these single-row-and-table inserts will required a > prepared transaction unless _all_ transactions use them (do they? And if > they do, why does my 2-datanode test work?). > > > Problem 1: If I use a single client, inserts seem to get stuck after about > 12 (running a batch file with 6014 individual insert statements). The > process doing inserts (psql) just stops doing inserts and I don't see any > output anywhere. > > Problem 2: If I use 64 clients connecting to all 3 coordinators (round > robin so approx. 21 clients each) I get 'Failed to get pooled connection' > errors. > > Problem 3: If I get 'Failed to get pooled connection' errors, the cluster > is in a broken state from then on. The only solution I've found is to > dropdb then createdb which usually can't be accomplished without stopping > the entire cluster and restarting it. > > What am I doing wrong? > > Chris... > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general |
|
From: Ashutosh B. <ash...@en...> - 2013-03-21 04:51:53
|
Hi Arni, There are various scenarios under which we push join, it's difficult to elaborate all of them. Between 1.0 and current head there have been a whole bunch of changes in join push-down. You will find that in current head, even the non-shippable joins are very fast, per my measurement and Suzuki-san's measurement 100 times), owing to merge/hash join instead of nested loop join. Which version are you trying out? Can you please try the current head (for testing only, not production). It will help you can specify your table structures, and queries. On Thu, Mar 21, 2013 at 8:39 AM, Koichi Suzuki <koi...@gm...>wrote: > Hi, > > XC pushes down join when join column of both table are distribution > column if both tables are distributed by hash or modulo. If one of > the tables is replicated table or both tables are replicated table, > join will be pushed down too. We have much more variety of the > statement context. If you share your table structure (create table > etc.), statement and its plan, it will be helpful if there's something > wrong or if there's something helping. > > I hope Ashutosh will answer the question better. > > Regards; > ---------- > Koichi Suzuki > > > 2013/3/21 Arni Sumarlidason <Arn...@md...>: > > What kind of logic does pgxc use to determine if a join can be can at > the data node level vs the coordinator node level? > > > > My joins are occurring at the coordinator and the data is overwhelming > the coordinator. I asked a similar question before, I thought this time I'd > be more generic and focus on the core problem. > > > > Arni > > Sent from my iPhone > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_d2d_mar > > _______________________________________________ > > Postgres-xc-general mailing list > > Pos...@li... > > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Enterprise Postgres Company |
|
From: Koichi S. <koi...@gm...> - 2013-03-21 04:39:21
|
Hi, XC pushes down join when join column of both table are distribution column if both tables are distributed by hash or modulo. If one of the tables is replicated table or both tables are replicated table, join will be pushed down too. We have much more variety of the statement context. If you share your table structure (create table etc.), statement and its plan, it will be helpful if there's something wrong or if there's something helping. I hope Ashutosh will answer the question better. Regards; ---------- Koichi Suzuki 2013/3/21 Arni Sumarlidason <Arn...@md...>: > What kind of logic does pgxc use to determine if a join can be can at the data node level vs the coordinator node level? > > My joins are occurring at the coordinator and the data is overwhelming the coordinator. I asked a similar question before, I thought this time I'd be more generic and focus on the core problem. > > Arni > Sent from my iPhone > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Postgres-xc-general mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-general |
|
From: Arni S. <Arn...@md...> - 2013-03-21 02:28:04
|
What kind of logic does pgxc use to determine if a join can be can at the data node level vs the coordinator node level? My joins are occurring at the coordinator and the data is overwhelming the coordinator. I asked a similar question before, I thought this time I'd be more generic and focus on the core problem. Arni Sent from my iPhone |
|
From: Chris B. <cb...@in...> - 2013-03-20 15:46:11
|
Hi all, I have previously run successful tests with 2 datanodes and I'm trying to run the same test with 3 datanodes. I am able to create/drop tables and insert/select rows from all 3 coordinators. The test runs if I point it at a single coordinator (doesn't matter which one) and set the number of clients to 32. Each datanode box is running datanode+coordinator(master)+gtm_proxy and gtm is running on a 4th box. I have upped max_pool_size on the coordinator and max_connections on the datanode to 400. I haven't upped max_prepared_transactions however I don't think any of these single-row-and-table inserts will required a prepared transaction unless _all_ transactions use them (do they? And if they do, why does my 2-datanode test work?). Problem 1: If I use a single client, inserts seem to get stuck after about 12 (running a batch file with 6014 individual insert statements). The process doing inserts (psql) just stops doing inserts and I don't see any output anywhere. Problem 2: If I use 64 clients connecting to all 3 coordinators (round robin so approx. 21 clients each) I get 'Failed to get pooled connection' errors. Problem 3: If I get 'Failed to get pooled connection' errors, the cluster is in a broken state from then on. The only solution I've found is to dropdb then createdb which usually can't be accomplished without stopping the entire cluster and restarting it. What am I doing wrong? Chris... |
|
From: Jim M. <ji...@gm...> - 2013-03-19 23:28:08
|
My guess, looking at the graphs, is that you're checkpointing in the middle of the test. If you set your checkpoint_timeout and checkout_segments high enough and do a manual checkpoint before the test, you shouldn't checkpoint during the test. checkpoint_segments=256 checkpoint_timeout=30min You'll need to restart for those settings to take effect. The from psql, run: postgres=# checkpoint; On Tue, Mar 19, 2013 at 6:41 PM, Chris Brown <cb...@in...> wrote: > Ahhh, you were right, the pgxc (64 clients without gtm_proxy) has almost exactly the same usage characteristics as pg (32 clients non-xc). > > I find this puzzling. If each of the two boxes is doing slightly more than half the work, why does it appear that they're both still nearly bottlenecked on disk? I can understand the CPU if the coordinator/datanode design isn't optimized yet. > > Chris... > ________________________________________ > From: Chris Brown > Sent: March 19, 2013 3:01 PM > To: Jim Mlodgenski > Cc: pos...@li... > Subject: RE: [Postgres-xc-general] PG-XC Performance > > I managed to get some more instrumentation results... > > PG waffles between disk-bound and CPU bound. CPU wavers around 90% across all CPUs and the disk spikes up and down from 25% to 95%. > > PG-XC (using GTM-proxy) seems to be CPU bound with around 95% CPU throughout the test. One CPU core is consistently nearly 100% throughout the test on both datanodes. Disk is high but not as high or as spikey as PG, ranging from 20% (most of the time) to 80%. > > I haven't been able to figure out how much memory the raid card has. It is an HPSA 410i which comes in at least 3 variants. > > I will run the fsync-off test asap but that probably won't be 'til tomorrow (deadlines). Honestly, though, I don't care that NDB is faster - the difference between PG and NDB is meaningless since I know that's apples-to-oranges (I need it as a known baseline for a presentation so I included it here). I'm also going to run this test using 3 datanode servers to see how the bottlenecks change. > > Chris... > > ________________________________________ > From: Jim Mlodgenski [ji...@gm...] > Sent: March 19, 2013 10:23 AM > To: Chris Brown > Cc: pos...@li... > Subject: Re: [Postgres-xc-general] PG-XC Performance > > How big is the RAID controller's cache? You're probably pushing > several gig of data through it on you're XC and PostgreSQL tests so > you're likely flooding it to the point where it needs to wait to flush > to disk even when you're adding the second XC datanode. > > If you wanted to have a more apples-to-apples comparison to NDB, you > can shut off some of the durability requirements that PostgreSQL has > on by default. > http://www.postgresql.org/docs/9.1/static/non-durability.html > > fsync=off > full_page_writes=off > synchronous_commit=off > checkpoint_segments=64 > > You wouldn't run with these setting in production unless you are OK > with potentially corrupted data, but it does get you close to what NDB > does under the covers. > > On Tue, Mar 19, 2013 at 1:07 PM, Chris Brown <cb...@in...> wrote: >> Yes, by round robin so it's not perfect, but it's probably good enough. >> >> On 13-03-19 10:06 AM, "Jim Mlodgenski" <ji...@gm...> wrote: >> >>>For your XC test, are you splitting your connections across the >>>coordinators with half of your psql sessions pointing to q1 and half >>>to q2? >>> >>>On Tue, Mar 19, 2013 at 1:01 PM, Chris Brown <cb...@in...> wrote: >>>> For PG (no-XC) it looks like I'm pegged on disk (still getting better >>>> instrumentation). I would expect that my disk usage would be nearly >>>> halved when striping data - still gathering info though. >>>> >>>> On 13-03-19 8:40 AM, "Jim Mlodgenski" <ji...@gm...> wrote: >>>> >>>>>It may be easier to just concentrate on the PostgreSQL test to find >>>>>the bottleneck. The fact that the XC test (without GTM Proxy) and the >>>>>PostgreSQL test is so similar, is leading me to believe you're hitting >>>>>the same bottleneck. >>>>> >>>>>On Tue, Mar 19, 2013 at 11:35 AM, Chris Brown <cb...@in...> >>>>>wrote: >>>>>> I assume I'm I/O bound. The CPU on the datanode/coordinator/gtm_proxy >>>>>>boxes gets to around 85%. I'll need some more instrumentation to be >>>>>>sure - I'll get back to you with details. >>>>>> >>>>>> Chris... >>>>>> >>>>>> ________________________________________ >>>>>> From: Jim Mlodgenski [ji...@gm...] >>>>>> Sent: March 19, 2013 8:32 AM >>>>>> To: Chris Brown >>>>>> Cc: pos...@li... >>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>>> >>>>>> When running the test against straight PostgreSQL, where is the >>>>>> bottleneck? Are you CPU bound or IO bound? >>>>>> >>>>>> On Tue, Mar 19, 2013 at 10:59 AM, Chris Brown <cb...@in...> >>>>>>wrote: >>>>>>> I also just discovered that my assumption about postgres (non xc) >>>>>>>being 9.2 was incorrect: >>>>>>> postgresql-server-9.1.7-1.fc16.x86_64 >>>>>>> Oops, sorry about the misinformation. >>>>>>> >>>>>>> Chris... >>>>>>> ________________________________________ >>>>>>> From: Chris Brown [cb...@in...] >>>>>>> Sent: March 19, 2013 7:45 AM >>>>>>> To: Jim Mlodgenski >>>>>>> Cc: pos...@li... >>>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>>>> >>>>>>> Hi Jim, >>>>>>> >>>>>>> I believe I'm doing an fsync (fdatasync) for each commit. I'm doing >>>>>>>the inserts as actual inserts performed by psql. They are not batched >>>>>>>- there is one insert per line and each file contains about 10,000 >>>>>>>inserts. This was a conscious choice since I was testing expected >>>>>>>transaction rate as opposed to import rate. >>>>>>> >>>>>>> I haven't done much tuning to postgres. Datanodes received this: >>>>>>> checkpoint_segements=32 >>>>>>> effective_cache_size=4GB >>>>>>> shared_buffers=4GB >>>>>>> random_page_cost=3.0 >>>>>>> For the coordinators, no tuning was done. >>>>>>> For xc, I also added: >>>>>>> max_prepared_transactions = 10 >>>>>>> gtm_host = 'localhost' # or the remote host, as appropriate on >>>>>>>coordinators >>>>>>> gtm_port = 6666 >>>>>>> Otherwise the postgresql.conf file is the default one provided by >>>>>>>initdb. If I understand this, then in linux (3.1.9-1.fc16.x86_64) I >>>>>>>am >>>>>>>using the defaults of wal_level(minimum), fsync(on), >>>>>>>wal_sync_method(fdatasync). >>>>>>> >>>>>>> I reran the 60 client test with explicit DISTRIBUTE BY HASH and >>>>>>>MODULO, confirming the obj_MODULO and obj_HASH in the tables: >>>>>>> "table_11_obj_MODULO_idx" btree ("obj_MODULO") >>>>>>> It didn't make an appreciable difference (~10 seconds on a 5m50s >>>>>>>test) >>>>>>>which leads me to believe that the 5m50s number is slightly in error. >>>>>>> >>>>>>> Chris... >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: Jim Mlodgenski [ji...@gm...] >>>>>>> Sent: March 19, 2013 7:26 AM >>>>>>> To: Chris Brown >>>>>>> Cc: Koichi Suzuki; pos...@li... >>>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>>>> >>>>>>> Can you send along some more details of the test? I find it odd that >>>>>>> in every scenario, the load times are consistent despite the change >>>>>>>in >>>>>>> the number of threads. Are you committing your transaction after each >>>>>>> insert? If so, your limiting factor is probably the fsync to disk >>>>>>> which would account for why PostgreSQL 9.2 is about the same speed as >>>>>>> XC 1.0. >>>>>>> >>>>>>> On Tue, Mar 19, 2013 at 10:06 AM, Chris Brown <cb...@in...> >>>>>>>wrote: >>>>>>>> Here's a sample table: >>>>>>>> >>>>>>>> CREATE TABLE table_11 ( >>>>>>>> "part" int not null, >>>>>>>> "key1" bigint not null, >>>>>>>> "key2" bigint not null, >>>>>>>> "col_1" varchar(23), >>>>>>>> "col_2" varchar(5), >>>>>>>> "col_3" varchar(32), >>>>>>>> "col_4" varchar(5), >>>>>>>> PRIMARY KEY(part,key1,key2) >>>>>>>> ); >>>>>>>> >>>>>>>> I guess I'm not specifying a distribution key. I assumed, perhaps >>>>>>>>incorrectly, that hash on the first element of the primary key would >>>>>>>>be the default. I will try a run with an explicit DISTRIBUTE BY >>>>>>>>HASH(part). >>>>>>>> >>>>>>>> Chris... >>>>>>>> ________________________________________ >>>>>>>> From: Koichi Suzuki [koi...@gm...] >>>>>>>> Sent: March 18, 2013 10:47 PM >>>>>>>> To: Chris Brown >>>>>>>> Cc: pos...@li... >>>>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>>>>> >>>>>>>> What kind of distribution did you use in your case? If all the >>>>>>>> tables are replicated, all the inserts are associated with implicit >>>>>>>> 2PCs. Frequently-updated tables should be distributed (hash will >>>>>>>>be >>>>>>>> better if the table has a suitable column). >>>>>>>> >>>>>>>> Regards; >>>>>>>> ---------- >>>>>>>> Koichi Suzuki >>>>>>>> >>>>>>>> >>>>>>>> 2013/3/19 Chris Brown <cb...@in...>: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I've been doing some performance testing of PostgreSQL-XC. My >>>>>>>>>workload is >>>>>>>>> all insert in this case. I was expecting PG-XC to perform worse >>>>>>>>>than the >>>>>>>>> alternatives but I was shocked by how much worse it was than >>>>>>>>>PostgreSQL. >>>>>>>>> I'm well aware that NDB has durability and features issues so I >>>>>>>>>expected >>>>>>>>> it to perform better - I don't consider the 0.8 to be particularly >>>>>>>>> interesting. I'd like anyone's thoughts on this. >>>>>>>>> >>>>>>>>> Chris... >>>>>>>>> >>>>>>>>> >>>>>>>>> Results: >>>>>>>>> >>>>>>>>> All results are very approximate! >>>>>>>>> CPU is an estimate on the number of cores used by server processes >>>>>>>>> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy). >>>>>>>>> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline >>>>>>>>>and is >>>>>>>>> intended to represent a comparative CPU cost for a single insert >>>>>>>>> transaction. >>>>>>>>> >>>>>>>>> Client PostgreSQL PostgreSQL-XC MySQL >>>>>>>>>Cluster >>>>>>>>> PostgreSQL-XC-2 >>>>>>>>> Threads Time CPU TC Time CPU TC Time >>>>>>>>>CPU >>>>>>>>> TC Time CPU TC >>>>>>>>> 16 5m08s 4.3 cores 1.0 >>>>>>>>> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9 >>>>>>>>> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s >>>>>>>>>7.8 >>>>>>>>> cores 0.8 >>>>>>>>> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s >>>>>>>>>8.0 >>>>>>>>> cores 0.8 6m06s 10.2 cores 2.7 >>>>>>>>> 64 5m01s 13.1 cores 2.9 2m11s >>>>>>>>>8.3 >>>>>>>>> cores 0.8 5m50s 10.5 cores 2.7 >>>>>>>>> 96 2m13s >>>>>>>>>8.4 >>>>>>>>> cores 0.8 >>>>>>>>> >>>>>>>>> >>>>>>>>> Configurations: >>>>>>>>> >>>>>>>>> PostgreSQL: >>>>>>>>> Datanodes q1 >>>>>>>>> Version: 9.2.x (redhat) >>>>>>>>> >>>>>>>>> PostgreSQL-XC: >>>>>>>>> Datanodes q1-q2 (striped) >>>>>>>>> Coordinators q1-q2 >>>>>>>>> GTM q3 >>>>>>>>> Version 9.1.7 (tar) >>>>>>>>> >>>>>>>>> PostgreSQL-XC-2: >>>>>>>>> Datanodes q1-q2 (striped) >>>>>>>>> Coordinators q1-q2 >>>>>>>>> GTM Proxy q1-q2 >>>>>>>>> GTM q3 >>>>>>>>> Version 9.1.7 (tar) >>>>>>>>> >>>>>>>>> MySQL Cluster: >>>>>>>>> ndbmtd q1-q2 (striped) >>>>>>>>> mysqld q1-q2 >>>>>>>>> ndb_mgmd q1 >>>>>>>>> Version 7.1.17 (oracle rhel 5) >>>>>>>>> >>>>>>>>> q1, q2, q3 are identical boxes each with: >>>>>>>>> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed >>>>>>>>>ram >>>>>>>>>and 3 >>>>>>>>> platters in raid 5. >>>>>>>>> They are lan local with a vlan-aware switch (I don't know which one >>>>>>>>>and I >>>>>>>>> didn't check to see if it was saturated). >>>>>>>>> >>>>>>>>> >>>>>>>>> Tables & Data: >>>>>>>>> >>>>>>>>> 161 tables with primary key ("part" int not null, "key1" bigint not >>>>>>>>>null, >>>>>>>>> "key2" bigint not null). Each table has a selection of varchar >>>>>>>>>columns >>>>>>>>> typically less than varchar(80). All non-primary-key columns have >>>>>>>>> non-unique indexes. 5.8 million rows were imported with a >>>>>>>>>different >>>>>>>>> number of rows to each table. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>-------------------------------------------------------------------- >>>>>>>>>-- >>>>>>>>>-------- >>>>>>>>> Everyone hates slow websites. So do we. >>>>>>>>> Make your web apps faster with AppDynamics >>>>>>>>> Download AppDynamics Lite for free today: >>>>>>>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>>>>>>> _______________________________________________ >>>>>>>>> Postgres-xc-general mailing list >>>>>>>>> Pos...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>>>>>>> >>>>>>>> >>>>>>>>--------------------------------------------------------------------- >>>>>>>>-- >>>>>>>>------- >>>>>>>> Everyone hates slow websites. So do we. >>>>>>>> Make your web apps faster with AppDynamics >>>>>>>> Download AppDynamics Lite for free today: >>>>>>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>>>>>> _______________________________________________ >>>>>>>> Postgres-xc-general mailing list >>>>>>>> Pos...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>>>>>> >>>>>>> >>>>>>>---------------------------------------------------------------------- >>>>>>>-- >>>>>>>------ >>>>>>> Everyone hates slow websites. So do we. >>>>>>> Make your web apps faster with AppDynamics >>>>>>> Download AppDynamics Lite for free today: >>>>>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>>>>> _______________________________________________ >>>>>>> Postgres-xc-general mailing list >>>>>>> Pos...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>>> >> |
|
From: Chris B. <cb...@in...> - 2013-03-19 22:41:56
|
Ahhh, you were right, the pgxc (64 clients without gtm_proxy) has almost exactly the same usage characteristics as pg (32 clients non-xc). I find this puzzling. If each of the two boxes is doing slightly more than half the work, why does it appear that they're both still nearly bottlenecked on disk? I can understand the CPU if the coordinator/datanode design isn't optimized yet. Chris... ________________________________________ From: Chris Brown Sent: March 19, 2013 3:01 PM To: Jim Mlodgenski Cc: pos...@li... Subject: RE: [Postgres-xc-general] PG-XC Performance I managed to get some more instrumentation results... PG waffles between disk-bound and CPU bound. CPU wavers around 90% across all CPUs and the disk spikes up and down from 25% to 95%. PG-XC (using GTM-proxy) seems to be CPU bound with around 95% CPU throughout the test. One CPU core is consistently nearly 100% throughout the test on both datanodes. Disk is high but not as high or as spikey as PG, ranging from 20% (most of the time) to 80%. I haven't been able to figure out how much memory the raid card has. It is an HPSA 410i which comes in at least 3 variants. I will run the fsync-off test asap but that probably won't be 'til tomorrow (deadlines). Honestly, though, I don't care that NDB is faster - the difference between PG and NDB is meaningless since I know that's apples-to-oranges (I need it as a known baseline for a presentation so I included it here). I'm also going to run this test using 3 datanode servers to see how the bottlenecks change. Chris... ________________________________________ From: Jim Mlodgenski [ji...@gm...] Sent: March 19, 2013 10:23 AM To: Chris Brown Cc: pos...@li... Subject: Re: [Postgres-xc-general] PG-XC Performance How big is the RAID controller's cache? You're probably pushing several gig of data through it on you're XC and PostgreSQL tests so you're likely flooding it to the point where it needs to wait to flush to disk even when you're adding the second XC datanode. If you wanted to have a more apples-to-apples comparison to NDB, you can shut off some of the durability requirements that PostgreSQL has on by default. http://www.postgresql.org/docs/9.1/static/non-durability.html fsync=off full_page_writes=off synchronous_commit=off checkpoint_segments=64 You wouldn't run with these setting in production unless you are OK with potentially corrupted data, but it does get you close to what NDB does under the covers. On Tue, Mar 19, 2013 at 1:07 PM, Chris Brown <cb...@in...> wrote: > Yes, by round robin so it's not perfect, but it's probably good enough. > > On 13-03-19 10:06 AM, "Jim Mlodgenski" <ji...@gm...> wrote: > >>For your XC test, are you splitting your connections across the >>coordinators with half of your psql sessions pointing to q1 and half >>to q2? >> >>On Tue, Mar 19, 2013 at 1:01 PM, Chris Brown <cb...@in...> wrote: >>> For PG (no-XC) it looks like I'm pegged on disk (still getting better >>> instrumentation). I would expect that my disk usage would be nearly >>> halved when striping data - still gathering info though. >>> >>> On 13-03-19 8:40 AM, "Jim Mlodgenski" <ji...@gm...> wrote: >>> >>>>It may be easier to just concentrate on the PostgreSQL test to find >>>>the bottleneck. The fact that the XC test (without GTM Proxy) and the >>>>PostgreSQL test is so similar, is leading me to believe you're hitting >>>>the same bottleneck. >>>> >>>>On Tue, Mar 19, 2013 at 11:35 AM, Chris Brown <cb...@in...> >>>>wrote: >>>>> I assume I'm I/O bound. The CPU on the datanode/coordinator/gtm_proxy >>>>>boxes gets to around 85%. I'll need some more instrumentation to be >>>>>sure - I'll get back to you with details. >>>>> >>>>> Chris... >>>>> >>>>> ________________________________________ >>>>> From: Jim Mlodgenski [ji...@gm...] >>>>> Sent: March 19, 2013 8:32 AM >>>>> To: Chris Brown >>>>> Cc: pos...@li... >>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>> >>>>> When running the test against straight PostgreSQL, where is the >>>>> bottleneck? Are you CPU bound or IO bound? >>>>> >>>>> On Tue, Mar 19, 2013 at 10:59 AM, Chris Brown <cb...@in...> >>>>>wrote: >>>>>> I also just discovered that my assumption about postgres (non xc) >>>>>>being 9.2 was incorrect: >>>>>> postgresql-server-9.1.7-1.fc16.x86_64 >>>>>> Oops, sorry about the misinformation. >>>>>> >>>>>> Chris... >>>>>> ________________________________________ >>>>>> From: Chris Brown [cb...@in...] >>>>>> Sent: March 19, 2013 7:45 AM >>>>>> To: Jim Mlodgenski >>>>>> Cc: pos...@li... >>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>>> >>>>>> Hi Jim, >>>>>> >>>>>> I believe I'm doing an fsync (fdatasync) for each commit. I'm doing >>>>>>the inserts as actual inserts performed by psql. They are not batched >>>>>>- there is one insert per line and each file contains about 10,000 >>>>>>inserts. This was a conscious choice since I was testing expected >>>>>>transaction rate as opposed to import rate. >>>>>> >>>>>> I haven't done much tuning to postgres. Datanodes received this: >>>>>> checkpoint_segements=32 >>>>>> effective_cache_size=4GB >>>>>> shared_buffers=4GB >>>>>> random_page_cost=3.0 >>>>>> For the coordinators, no tuning was done. >>>>>> For xc, I also added: >>>>>> max_prepared_transactions = 10 >>>>>> gtm_host = 'localhost' # or the remote host, as appropriate on >>>>>>coordinators >>>>>> gtm_port = 6666 >>>>>> Otherwise the postgresql.conf file is the default one provided by >>>>>>initdb. If I understand this, then in linux (3.1.9-1.fc16.x86_64) I >>>>>>am >>>>>>using the defaults of wal_level(minimum), fsync(on), >>>>>>wal_sync_method(fdatasync). >>>>>> >>>>>> I reran the 60 client test with explicit DISTRIBUTE BY HASH and >>>>>>MODULO, confirming the obj_MODULO and obj_HASH in the tables: >>>>>> "table_11_obj_MODULO_idx" btree ("obj_MODULO") >>>>>> It didn't make an appreciable difference (~10 seconds on a 5m50s >>>>>>test) >>>>>>which leads me to believe that the 5m50s number is slightly in error. >>>>>> >>>>>> Chris... >>>>>> >>>>>> ________________________________________ >>>>>> From: Jim Mlodgenski [ji...@gm...] >>>>>> Sent: March 19, 2013 7:26 AM >>>>>> To: Chris Brown >>>>>> Cc: Koichi Suzuki; pos...@li... >>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>>> >>>>>> Can you send along some more details of the test? I find it odd that >>>>>> in every scenario, the load times are consistent despite the change >>>>>>in >>>>>> the number of threads. Are you committing your transaction after each >>>>>> insert? If so, your limiting factor is probably the fsync to disk >>>>>> which would account for why PostgreSQL 9.2 is about the same speed as >>>>>> XC 1.0. >>>>>> >>>>>> On Tue, Mar 19, 2013 at 10:06 AM, Chris Brown <cb...@in...> >>>>>>wrote: >>>>>>> Here's a sample table: >>>>>>> >>>>>>> CREATE TABLE table_11 ( >>>>>>> "part" int not null, >>>>>>> "key1" bigint not null, >>>>>>> "key2" bigint not null, >>>>>>> "col_1" varchar(23), >>>>>>> "col_2" varchar(5), >>>>>>> "col_3" varchar(32), >>>>>>> "col_4" varchar(5), >>>>>>> PRIMARY KEY(part,key1,key2) >>>>>>> ); >>>>>>> >>>>>>> I guess I'm not specifying a distribution key. I assumed, perhaps >>>>>>>incorrectly, that hash on the first element of the primary key would >>>>>>>be the default. I will try a run with an explicit DISTRIBUTE BY >>>>>>>HASH(part). >>>>>>> >>>>>>> Chris... >>>>>>> ________________________________________ >>>>>>> From: Koichi Suzuki [koi...@gm...] >>>>>>> Sent: March 18, 2013 10:47 PM >>>>>>> To: Chris Brown >>>>>>> Cc: pos...@li... >>>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>>>> >>>>>>> What kind of distribution did you use in your case? If all the >>>>>>> tables are replicated, all the inserts are associated with implicit >>>>>>> 2PCs. Frequently-updated tables should be distributed (hash will >>>>>>>be >>>>>>> better if the table has a suitable column). >>>>>>> >>>>>>> Regards; >>>>>>> ---------- >>>>>>> Koichi Suzuki >>>>>>> >>>>>>> >>>>>>> 2013/3/19 Chris Brown <cb...@in...>: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I've been doing some performance testing of PostgreSQL-XC. My >>>>>>>>workload is >>>>>>>> all insert in this case. I was expecting PG-XC to perform worse >>>>>>>>than the >>>>>>>> alternatives but I was shocked by how much worse it was than >>>>>>>>PostgreSQL. >>>>>>>> I'm well aware that NDB has durability and features issues so I >>>>>>>>expected >>>>>>>> it to perform better - I don't consider the 0.8 to be particularly >>>>>>>> interesting. I'd like anyone's thoughts on this. >>>>>>>> >>>>>>>> Chris... >>>>>>>> >>>>>>>> >>>>>>>> Results: >>>>>>>> >>>>>>>> All results are very approximate! >>>>>>>> CPU is an estimate on the number of cores used by server processes >>>>>>>> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy). >>>>>>>> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline >>>>>>>>and is >>>>>>>> intended to represent a comparative CPU cost for a single insert >>>>>>>> transaction. >>>>>>>> >>>>>>>> Client PostgreSQL PostgreSQL-XC MySQL >>>>>>>>Cluster >>>>>>>> PostgreSQL-XC-2 >>>>>>>> Threads Time CPU TC Time CPU TC Time >>>>>>>>CPU >>>>>>>> TC Time CPU TC >>>>>>>> 16 5m08s 4.3 cores 1.0 >>>>>>>> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9 >>>>>>>> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s >>>>>>>>7.8 >>>>>>>> cores 0.8 >>>>>>>> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s >>>>>>>>8.0 >>>>>>>> cores 0.8 6m06s 10.2 cores 2.7 >>>>>>>> 64 5m01s 13.1 cores 2.9 2m11s >>>>>>>>8.3 >>>>>>>> cores 0.8 5m50s 10.5 cores 2.7 >>>>>>>> 96 2m13s >>>>>>>>8.4 >>>>>>>> cores 0.8 >>>>>>>> >>>>>>>> >>>>>>>> Configurations: >>>>>>>> >>>>>>>> PostgreSQL: >>>>>>>> Datanodes q1 >>>>>>>> Version: 9.2.x (redhat) >>>>>>>> >>>>>>>> PostgreSQL-XC: >>>>>>>> Datanodes q1-q2 (striped) >>>>>>>> Coordinators q1-q2 >>>>>>>> GTM q3 >>>>>>>> Version 9.1.7 (tar) >>>>>>>> >>>>>>>> PostgreSQL-XC-2: >>>>>>>> Datanodes q1-q2 (striped) >>>>>>>> Coordinators q1-q2 >>>>>>>> GTM Proxy q1-q2 >>>>>>>> GTM q3 >>>>>>>> Version 9.1.7 (tar) >>>>>>>> >>>>>>>> MySQL Cluster: >>>>>>>> ndbmtd q1-q2 (striped) >>>>>>>> mysqld q1-q2 >>>>>>>> ndb_mgmd q1 >>>>>>>> Version 7.1.17 (oracle rhel 5) >>>>>>>> >>>>>>>> q1, q2, q3 are identical boxes each with: >>>>>>>> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed >>>>>>>>ram >>>>>>>>and 3 >>>>>>>> platters in raid 5. >>>>>>>> They are lan local with a vlan-aware switch (I don't know which one >>>>>>>>and I >>>>>>>> didn't check to see if it was saturated). >>>>>>>> >>>>>>>> >>>>>>>> Tables & Data: >>>>>>>> >>>>>>>> 161 tables with primary key ("part" int not null, "key1" bigint not >>>>>>>>null, >>>>>>>> "key2" bigint not null). Each table has a selection of varchar >>>>>>>>columns >>>>>>>> typically less than varchar(80). All non-primary-key columns have >>>>>>>> non-unique indexes. 5.8 million rows were imported with a >>>>>>>>different >>>>>>>> number of rows to each table. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>-------------------------------------------------------------------- >>>>>>>>-- >>>>>>>>-------- >>>>>>>> Everyone hates slow websites. So do we. >>>>>>>> Make your web apps faster with AppDynamics >>>>>>>> Download AppDynamics Lite for free today: >>>>>>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>>>>>> _______________________________________________ >>>>>>>> Postgres-xc-general mailing list >>>>>>>> Pos...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>>>>>> >>>>>>> >>>>>>>--------------------------------------------------------------------- >>>>>>>-- >>>>>>>------- >>>>>>> Everyone hates slow websites. So do we. >>>>>>> Make your web apps faster with AppDynamics >>>>>>> Download AppDynamics Lite for free today: >>>>>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>>>>> _______________________________________________ >>>>>>> Postgres-xc-general mailing list >>>>>>> Pos...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>>>>> >>>>>> >>>>>>---------------------------------------------------------------------- >>>>>>-- >>>>>>------ >>>>>> Everyone hates slow websites. So do we. >>>>>> Make your web apps faster with AppDynamics >>>>>> Download AppDynamics Lite for free today: >>>>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>>>> _______________________________________________ >>>>>> Postgres-xc-general mailing list >>>>>> Pos...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>> > |
|
From: Chris B. <cb...@in...> - 2013-03-19 22:01:34
|
I managed to get some more instrumentation results... PG waffles between disk-bound and CPU bound. CPU wavers around 90% across all CPUs and the disk spikes up and down from 25% to 95%. PG-XC (using GTM-proxy) seems to be CPU bound with around 95% CPU throughout the test. One CPU core is consistently nearly 100% throughout the test on both datanodes. Disk is high but not as high or as spikey as PG, ranging from 20% (most of the time) to 80%. I haven't been able to figure out how much memory the raid card has. It is an HPSA 410i which comes in at least 3 variants. I will run the fsync-off test asap but that probably won't be 'til tomorrow (deadlines). Honestly, though, I don't care that NDB is faster - the difference between PG and NDB is meaningless since I know that's apples-to-oranges (I need it as a known baseline for a presentation so I included it here). I'm also going to run this test using 3 datanode servers to see how the bottlenecks change. Chris... ________________________________________ From: Jim Mlodgenski [ji...@gm...] Sent: March 19, 2013 10:23 AM To: Chris Brown Cc: pos...@li... Subject: Re: [Postgres-xc-general] PG-XC Performance How big is the RAID controller's cache? You're probably pushing several gig of data through it on you're XC and PostgreSQL tests so you're likely flooding it to the point where it needs to wait to flush to disk even when you're adding the second XC datanode. If you wanted to have a more apples-to-apples comparison to NDB, you can shut off some of the durability requirements that PostgreSQL has on by default. http://www.postgresql.org/docs/9.1/static/non-durability.html fsync=off full_page_writes=off synchronous_commit=off checkpoint_segments=64 You wouldn't run with these setting in production unless you are OK with potentially corrupted data, but it does get you close to what NDB does under the covers. On Tue, Mar 19, 2013 at 1:07 PM, Chris Brown <cb...@in...> wrote: > Yes, by round robin so it's not perfect, but it's probably good enough. > > On 13-03-19 10:06 AM, "Jim Mlodgenski" <ji...@gm...> wrote: > >>For your XC test, are you splitting your connections across the >>coordinators with half of your psql sessions pointing to q1 and half >>to q2? >> >>On Tue, Mar 19, 2013 at 1:01 PM, Chris Brown <cb...@in...> wrote: >>> For PG (no-XC) it looks like I'm pegged on disk (still getting better >>> instrumentation). I would expect that my disk usage would be nearly >>> halved when striping data - still gathering info though. >>> >>> On 13-03-19 8:40 AM, "Jim Mlodgenski" <ji...@gm...> wrote: >>> >>>>It may be easier to just concentrate on the PostgreSQL test to find >>>>the bottleneck. The fact that the XC test (without GTM Proxy) and the >>>>PostgreSQL test is so similar, is leading me to believe you're hitting >>>>the same bottleneck. >>>> >>>>On Tue, Mar 19, 2013 at 11:35 AM, Chris Brown <cb...@in...> >>>>wrote: >>>>> I assume I'm I/O bound. The CPU on the datanode/coordinator/gtm_proxy >>>>>boxes gets to around 85%. I'll need some more instrumentation to be >>>>>sure - I'll get back to you with details. >>>>> >>>>> Chris... >>>>> >>>>> ________________________________________ >>>>> From: Jim Mlodgenski [ji...@gm...] >>>>> Sent: March 19, 2013 8:32 AM >>>>> To: Chris Brown >>>>> Cc: pos...@li... >>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>> >>>>> When running the test against straight PostgreSQL, where is the >>>>> bottleneck? Are you CPU bound or IO bound? >>>>> >>>>> On Tue, Mar 19, 2013 at 10:59 AM, Chris Brown <cb...@in...> >>>>>wrote: >>>>>> I also just discovered that my assumption about postgres (non xc) >>>>>>being 9.2 was incorrect: >>>>>> postgresql-server-9.1.7-1.fc16.x86_64 >>>>>> Oops, sorry about the misinformation. >>>>>> >>>>>> Chris... >>>>>> ________________________________________ >>>>>> From: Chris Brown [cb...@in...] >>>>>> Sent: March 19, 2013 7:45 AM >>>>>> To: Jim Mlodgenski >>>>>> Cc: pos...@li... >>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>>> >>>>>> Hi Jim, >>>>>> >>>>>> I believe I'm doing an fsync (fdatasync) for each commit. I'm doing >>>>>>the inserts as actual inserts performed by psql. They are not batched >>>>>>- there is one insert per line and each file contains about 10,000 >>>>>>inserts. This was a conscious choice since I was testing expected >>>>>>transaction rate as opposed to import rate. >>>>>> >>>>>> I haven't done much tuning to postgres. Datanodes received this: >>>>>> checkpoint_segements=32 >>>>>> effective_cache_size=4GB >>>>>> shared_buffers=4GB >>>>>> random_page_cost=3.0 >>>>>> For the coordinators, no tuning was done. >>>>>> For xc, I also added: >>>>>> max_prepared_transactions = 10 >>>>>> gtm_host = 'localhost' # or the remote host, as appropriate on >>>>>>coordinators >>>>>> gtm_port = 6666 >>>>>> Otherwise the postgresql.conf file is the default one provided by >>>>>>initdb. If I understand this, then in linux (3.1.9-1.fc16.x86_64) I >>>>>>am >>>>>>using the defaults of wal_level(minimum), fsync(on), >>>>>>wal_sync_method(fdatasync). >>>>>> >>>>>> I reran the 60 client test with explicit DISTRIBUTE BY HASH and >>>>>>MODULO, confirming the obj_MODULO and obj_HASH in the tables: >>>>>> "table_11_obj_MODULO_idx" btree ("obj_MODULO") >>>>>> It didn't make an appreciable difference (~10 seconds on a 5m50s >>>>>>test) >>>>>>which leads me to believe that the 5m50s number is slightly in error. >>>>>> >>>>>> Chris... >>>>>> >>>>>> ________________________________________ >>>>>> From: Jim Mlodgenski [ji...@gm...] >>>>>> Sent: March 19, 2013 7:26 AM >>>>>> To: Chris Brown >>>>>> Cc: Koichi Suzuki; pos...@li... >>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>>> >>>>>> Can you send along some more details of the test? I find it odd that >>>>>> in every scenario, the load times are consistent despite the change >>>>>>in >>>>>> the number of threads. Are you committing your transaction after each >>>>>> insert? If so, your limiting factor is probably the fsync to disk >>>>>> which would account for why PostgreSQL 9.2 is about the same speed as >>>>>> XC 1.0. >>>>>> >>>>>> On Tue, Mar 19, 2013 at 10:06 AM, Chris Brown <cb...@in...> >>>>>>wrote: >>>>>>> Here's a sample table: >>>>>>> >>>>>>> CREATE TABLE table_11 ( >>>>>>> "part" int not null, >>>>>>> "key1" bigint not null, >>>>>>> "key2" bigint not null, >>>>>>> "col_1" varchar(23), >>>>>>> "col_2" varchar(5), >>>>>>> "col_3" varchar(32), >>>>>>> "col_4" varchar(5), >>>>>>> PRIMARY KEY(part,key1,key2) >>>>>>> ); >>>>>>> >>>>>>> I guess I'm not specifying a distribution key. I assumed, perhaps >>>>>>>incorrectly, that hash on the first element of the primary key would >>>>>>>be the default. I will try a run with an explicit DISTRIBUTE BY >>>>>>>HASH(part). >>>>>>> >>>>>>> Chris... >>>>>>> ________________________________________ >>>>>>> From: Koichi Suzuki [koi...@gm...] >>>>>>> Sent: March 18, 2013 10:47 PM >>>>>>> To: Chris Brown >>>>>>> Cc: pos...@li... >>>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>>>> >>>>>>> What kind of distribution did you use in your case? If all the >>>>>>> tables are replicated, all the inserts are associated with implicit >>>>>>> 2PCs. Frequently-updated tables should be distributed (hash will >>>>>>>be >>>>>>> better if the table has a suitable column). >>>>>>> >>>>>>> Regards; >>>>>>> ---------- >>>>>>> Koichi Suzuki >>>>>>> >>>>>>> >>>>>>> 2013/3/19 Chris Brown <cb...@in...>: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I've been doing some performance testing of PostgreSQL-XC. My >>>>>>>>workload is >>>>>>>> all insert in this case. I was expecting PG-XC to perform worse >>>>>>>>than the >>>>>>>> alternatives but I was shocked by how much worse it was than >>>>>>>>PostgreSQL. >>>>>>>> I'm well aware that NDB has durability and features issues so I >>>>>>>>expected >>>>>>>> it to perform better - I don't consider the 0.8 to be particularly >>>>>>>> interesting. I'd like anyone's thoughts on this. >>>>>>>> >>>>>>>> Chris... >>>>>>>> >>>>>>>> >>>>>>>> Results: >>>>>>>> >>>>>>>> All results are very approximate! >>>>>>>> CPU is an estimate on the number of cores used by server processes >>>>>>>> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy). >>>>>>>> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline >>>>>>>>and is >>>>>>>> intended to represent a comparative CPU cost for a single insert >>>>>>>> transaction. >>>>>>>> >>>>>>>> Client PostgreSQL PostgreSQL-XC MySQL >>>>>>>>Cluster >>>>>>>> PostgreSQL-XC-2 >>>>>>>> Threads Time CPU TC Time CPU TC Time >>>>>>>>CPU >>>>>>>> TC Time CPU TC >>>>>>>> 16 5m08s 4.3 cores 1.0 >>>>>>>> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9 >>>>>>>> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s >>>>>>>>7.8 >>>>>>>> cores 0.8 >>>>>>>> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s >>>>>>>>8.0 >>>>>>>> cores 0.8 6m06s 10.2 cores 2.7 >>>>>>>> 64 5m01s 13.1 cores 2.9 2m11s >>>>>>>>8.3 >>>>>>>> cores 0.8 5m50s 10.5 cores 2.7 >>>>>>>> 96 2m13s >>>>>>>>8.4 >>>>>>>> cores 0.8 >>>>>>>> >>>>>>>> >>>>>>>> Configurations: >>>>>>>> >>>>>>>> PostgreSQL: >>>>>>>> Datanodes q1 >>>>>>>> Version: 9.2.x (redhat) >>>>>>>> >>>>>>>> PostgreSQL-XC: >>>>>>>> Datanodes q1-q2 (striped) >>>>>>>> Coordinators q1-q2 >>>>>>>> GTM q3 >>>>>>>> Version 9.1.7 (tar) >>>>>>>> >>>>>>>> PostgreSQL-XC-2: >>>>>>>> Datanodes q1-q2 (striped) >>>>>>>> Coordinators q1-q2 >>>>>>>> GTM Proxy q1-q2 >>>>>>>> GTM q3 >>>>>>>> Version 9.1.7 (tar) >>>>>>>> >>>>>>>> MySQL Cluster: >>>>>>>> ndbmtd q1-q2 (striped) >>>>>>>> mysqld q1-q2 >>>>>>>> ndb_mgmd q1 >>>>>>>> Version 7.1.17 (oracle rhel 5) >>>>>>>> >>>>>>>> q1, q2, q3 are identical boxes each with: >>>>>>>> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed >>>>>>>>ram >>>>>>>>and 3 >>>>>>>> platters in raid 5. >>>>>>>> They are lan local with a vlan-aware switch (I don't know which one >>>>>>>>and I >>>>>>>> didn't check to see if it was saturated). >>>>>>>> >>>>>>>> >>>>>>>> Tables & Data: >>>>>>>> >>>>>>>> 161 tables with primary key ("part" int not null, "key1" bigint not >>>>>>>>null, >>>>>>>> "key2" bigint not null). Each table has a selection of varchar >>>>>>>>columns >>>>>>>> typically less than varchar(80). All non-primary-key columns have >>>>>>>> non-unique indexes. 5.8 million rows were imported with a >>>>>>>>different >>>>>>>> number of rows to each table. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>-------------------------------------------------------------------- >>>>>>>>-- >>>>>>>>-------- >>>>>>>> Everyone hates slow websites. So do we. >>>>>>>> Make your web apps faster with AppDynamics >>>>>>>> Download AppDynamics Lite for free today: >>>>>>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>>>>>> _______________________________________________ >>>>>>>> Postgres-xc-general mailing list >>>>>>>> Pos...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>>>>>> >>>>>>> >>>>>>>--------------------------------------------------------------------- >>>>>>>-- >>>>>>>------- >>>>>>> Everyone hates slow websites. So do we. >>>>>>> Make your web apps faster with AppDynamics >>>>>>> Download AppDynamics Lite for free today: >>>>>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>>>>> _______________________________________________ >>>>>>> Postgres-xc-general mailing list >>>>>>> Pos...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>>>>> >>>>>> >>>>>>---------------------------------------------------------------------- >>>>>>-- >>>>>>------ >>>>>> Everyone hates slow websites. So do we. >>>>>> Make your web apps faster with AppDynamics >>>>>> Download AppDynamics Lite for free today: >>>>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>>>> _______________________________________________ >>>>>> Postgres-xc-general mailing list >>>>>> Pos...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>> > |
|
From: Jim M. <ji...@gm...> - 2013-03-19 17:23:17
|
How big is the RAID controller's cache? You're probably pushing several gig of data through it on you're XC and PostgreSQL tests so you're likely flooding it to the point where it needs to wait to flush to disk even when you're adding the second XC datanode. If you wanted to have a more apples-to-apples comparison to NDB, you can shut off some of the durability requirements that PostgreSQL has on by default. http://www.postgresql.org/docs/9.1/static/non-durability.html fsync=off full_page_writes=off synchronous_commit=off checkpoint_segments=64 You wouldn't run with these setting in production unless you are OK with potentially corrupted data, but it does get you close to what NDB does under the covers. On Tue, Mar 19, 2013 at 1:07 PM, Chris Brown <cb...@in...> wrote: > Yes, by round robin so it's not perfect, but it's probably good enough. > > On 13-03-19 10:06 AM, "Jim Mlodgenski" <ji...@gm...> wrote: > >>For your XC test, are you splitting your connections across the >>coordinators with half of your psql sessions pointing to q1 and half >>to q2? >> >>On Tue, Mar 19, 2013 at 1:01 PM, Chris Brown <cb...@in...> wrote: >>> For PG (no-XC) it looks like I'm pegged on disk (still getting better >>> instrumentation). I would expect that my disk usage would be nearly >>> halved when striping data - still gathering info though. >>> >>> On 13-03-19 8:40 AM, "Jim Mlodgenski" <ji...@gm...> wrote: >>> >>>>It may be easier to just concentrate on the PostgreSQL test to find >>>>the bottleneck. The fact that the XC test (without GTM Proxy) and the >>>>PostgreSQL test is so similar, is leading me to believe you're hitting >>>>the same bottleneck. >>>> >>>>On Tue, Mar 19, 2013 at 11:35 AM, Chris Brown <cb...@in...> >>>>wrote: >>>>> I assume I'm I/O bound. The CPU on the datanode/coordinator/gtm_proxy >>>>>boxes gets to around 85%. I'll need some more instrumentation to be >>>>>sure - I'll get back to you with details. >>>>> >>>>> Chris... >>>>> >>>>> ________________________________________ >>>>> From: Jim Mlodgenski [ji...@gm...] >>>>> Sent: March 19, 2013 8:32 AM >>>>> To: Chris Brown >>>>> Cc: pos...@li... >>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>> >>>>> When running the test against straight PostgreSQL, where is the >>>>> bottleneck? Are you CPU bound or IO bound? >>>>> >>>>> On Tue, Mar 19, 2013 at 10:59 AM, Chris Brown <cb...@in...> >>>>>wrote: >>>>>> I also just discovered that my assumption about postgres (non xc) >>>>>>being 9.2 was incorrect: >>>>>> postgresql-server-9.1.7-1.fc16.x86_64 >>>>>> Oops, sorry about the misinformation. >>>>>> >>>>>> Chris... >>>>>> ________________________________________ >>>>>> From: Chris Brown [cb...@in...] >>>>>> Sent: March 19, 2013 7:45 AM >>>>>> To: Jim Mlodgenski >>>>>> Cc: pos...@li... >>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>>> >>>>>> Hi Jim, >>>>>> >>>>>> I believe I'm doing an fsync (fdatasync) for each commit. I'm doing >>>>>>the inserts as actual inserts performed by psql. They are not batched >>>>>>- there is one insert per line and each file contains about 10,000 >>>>>>inserts. This was a conscious choice since I was testing expected >>>>>>transaction rate as opposed to import rate. >>>>>> >>>>>> I haven't done much tuning to postgres. Datanodes received this: >>>>>> checkpoint_segements=32 >>>>>> effective_cache_size=4GB >>>>>> shared_buffers=4GB >>>>>> random_page_cost=3.0 >>>>>> For the coordinators, no tuning was done. >>>>>> For xc, I also added: >>>>>> max_prepared_transactions = 10 >>>>>> gtm_host = 'localhost' # or the remote host, as appropriate on >>>>>>coordinators >>>>>> gtm_port = 6666 >>>>>> Otherwise the postgresql.conf file is the default one provided by >>>>>>initdb. If I understand this, then in linux (3.1.9-1.fc16.x86_64) I >>>>>>am >>>>>>using the defaults of wal_level(minimum), fsync(on), >>>>>>wal_sync_method(fdatasync). >>>>>> >>>>>> I reran the 60 client test with explicit DISTRIBUTE BY HASH and >>>>>>MODULO, confirming the obj_MODULO and obj_HASH in the tables: >>>>>> "table_11_obj_MODULO_idx" btree ("obj_MODULO") >>>>>> It didn't make an appreciable difference (~10 seconds on a 5m50s >>>>>>test) >>>>>>which leads me to believe that the 5m50s number is slightly in error. >>>>>> >>>>>> Chris... >>>>>> >>>>>> ________________________________________ >>>>>> From: Jim Mlodgenski [ji...@gm...] >>>>>> Sent: March 19, 2013 7:26 AM >>>>>> To: Chris Brown >>>>>> Cc: Koichi Suzuki; pos...@li... >>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>>> >>>>>> Can you send along some more details of the test? I find it odd that >>>>>> in every scenario, the load times are consistent despite the change >>>>>>in >>>>>> the number of threads. Are you committing your transaction after each >>>>>> insert? If so, your limiting factor is probably the fsync to disk >>>>>> which would account for why PostgreSQL 9.2 is about the same speed as >>>>>> XC 1.0. >>>>>> >>>>>> On Tue, Mar 19, 2013 at 10:06 AM, Chris Brown <cb...@in...> >>>>>>wrote: >>>>>>> Here's a sample table: >>>>>>> >>>>>>> CREATE TABLE table_11 ( >>>>>>> "part" int not null, >>>>>>> "key1" bigint not null, >>>>>>> "key2" bigint not null, >>>>>>> "col_1" varchar(23), >>>>>>> "col_2" varchar(5), >>>>>>> "col_3" varchar(32), >>>>>>> "col_4" varchar(5), >>>>>>> PRIMARY KEY(part,key1,key2) >>>>>>> ); >>>>>>> >>>>>>> I guess I'm not specifying a distribution key. I assumed, perhaps >>>>>>>incorrectly, that hash on the first element of the primary key would >>>>>>>be the default. I will try a run with an explicit DISTRIBUTE BY >>>>>>>HASH(part). >>>>>>> >>>>>>> Chris... >>>>>>> ________________________________________ >>>>>>> From: Koichi Suzuki [koi...@gm...] >>>>>>> Sent: March 18, 2013 10:47 PM >>>>>>> To: Chris Brown >>>>>>> Cc: pos...@li... >>>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance >>>>>>> >>>>>>> What kind of distribution did you use in your case? If all the >>>>>>> tables are replicated, all the inserts are associated with implicit >>>>>>> 2PCs. Frequently-updated tables should be distributed (hash will >>>>>>>be >>>>>>> better if the table has a suitable column). >>>>>>> >>>>>>> Regards; >>>>>>> ---------- >>>>>>> Koichi Suzuki >>>>>>> >>>>>>> >>>>>>> 2013/3/19 Chris Brown <cb...@in...>: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I've been doing some performance testing of PostgreSQL-XC. My >>>>>>>>workload is >>>>>>>> all insert in this case. I was expecting PG-XC to perform worse >>>>>>>>than the >>>>>>>> alternatives but I was shocked by how much worse it was than >>>>>>>>PostgreSQL. >>>>>>>> I'm well aware that NDB has durability and features issues so I >>>>>>>>expected >>>>>>>> it to perform better - I don't consider the 0.8 to be particularly >>>>>>>> interesting. I'd like anyone's thoughts on this. >>>>>>>> >>>>>>>> Chris... >>>>>>>> >>>>>>>> >>>>>>>> Results: >>>>>>>> >>>>>>>> All results are very approximate! >>>>>>>> CPU is an estimate on the number of cores used by server processes >>>>>>>> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy). >>>>>>>> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline >>>>>>>>and is >>>>>>>> intended to represent a comparative CPU cost for a single insert >>>>>>>> transaction. >>>>>>>> >>>>>>>> Client PostgreSQL PostgreSQL-XC MySQL >>>>>>>>Cluster >>>>>>>> PostgreSQL-XC-2 >>>>>>>> Threads Time CPU TC Time CPU TC Time >>>>>>>>CPU >>>>>>>> TC Time CPU TC >>>>>>>> 16 5m08s 4.3 cores 1.0 >>>>>>>> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9 >>>>>>>> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s >>>>>>>>7.8 >>>>>>>> cores 0.8 >>>>>>>> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s >>>>>>>>8.0 >>>>>>>> cores 0.8 6m06s 10.2 cores 2.7 >>>>>>>> 64 5m01s 13.1 cores 2.9 2m11s >>>>>>>>8.3 >>>>>>>> cores 0.8 5m50s 10.5 cores 2.7 >>>>>>>> 96 2m13s >>>>>>>>8.4 >>>>>>>> cores 0.8 >>>>>>>> >>>>>>>> >>>>>>>> Configurations: >>>>>>>> >>>>>>>> PostgreSQL: >>>>>>>> Datanodes q1 >>>>>>>> Version: 9.2.x (redhat) >>>>>>>> >>>>>>>> PostgreSQL-XC: >>>>>>>> Datanodes q1-q2 (striped) >>>>>>>> Coordinators q1-q2 >>>>>>>> GTM q3 >>>>>>>> Version 9.1.7 (tar) >>>>>>>> >>>>>>>> PostgreSQL-XC-2: >>>>>>>> Datanodes q1-q2 (striped) >>>>>>>> Coordinators q1-q2 >>>>>>>> GTM Proxy q1-q2 >>>>>>>> GTM q3 >>>>>>>> Version 9.1.7 (tar) >>>>>>>> >>>>>>>> MySQL Cluster: >>>>>>>> ndbmtd q1-q2 (striped) >>>>>>>> mysqld q1-q2 >>>>>>>> ndb_mgmd q1 >>>>>>>> Version 7.1.17 (oracle rhel 5) >>>>>>>> >>>>>>>> q1, q2, q3 are identical boxes each with: >>>>>>>> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed >>>>>>>>ram >>>>>>>>and 3 >>>>>>>> platters in raid 5. >>>>>>>> They are lan local with a vlan-aware switch (I don't know which one >>>>>>>>and I >>>>>>>> didn't check to see if it was saturated). >>>>>>>> >>>>>>>> >>>>>>>> Tables & Data: >>>>>>>> >>>>>>>> 161 tables with primary key ("part" int not null, "key1" bigint not >>>>>>>>null, >>>>>>>> "key2" bigint not null). Each table has a selection of varchar >>>>>>>>columns >>>>>>>> typically less than varchar(80). All non-primary-key columns have >>>>>>>> non-unique indexes. 5.8 million rows were imported with a >>>>>>>>different >>>>>>>> number of rows to each table. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>-------------------------------------------------------------------- >>>>>>>>-- >>>>>>>>-------- >>>>>>>> Everyone hates slow websites. So do we. >>>>>>>> Make your web apps faster with AppDynamics >>>>>>>> Download AppDynamics Lite for free today: >>>>>>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>>>>>> _______________________________________________ >>>>>>>> Postgres-xc-general mailing list >>>>>>>> Pos...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>>>>>> >>>>>>> >>>>>>>--------------------------------------------------------------------- >>>>>>>-- >>>>>>>------- >>>>>>> Everyone hates slow websites. So do we. >>>>>>> Make your web apps faster with AppDynamics >>>>>>> Download AppDynamics Lite for free today: >>>>>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>>>>> _______________________________________________ >>>>>>> Postgres-xc-general mailing list >>>>>>> Pos...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>>>>> >>>>>> >>>>>>---------------------------------------------------------------------- >>>>>>-- >>>>>>------ >>>>>> Everyone hates slow websites. So do we. >>>>>> Make your web apps faster with AppDynamics >>>>>> Download AppDynamics Lite for free today: >>>>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>>>> _______________________________________________ >>>>>> Postgres-xc-general mailing list >>>>>> Pos...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general >>> > |
|
From: Chris B. <cb...@in...> - 2013-03-19 17:07:59
|
Yes, by round robin so it's not perfect, but it's probably good enough.
On 13-03-19 10:06 AM, "Jim Mlodgenski" <ji...@gm...> wrote:
>For your XC test, are you splitting your connections across the
>coordinators with half of your psql sessions pointing to q1 and half
>to q2?
>
>On Tue, Mar 19, 2013 at 1:01 PM, Chris Brown <cb...@in...> wrote:
>> For PG (no-XC) it looks like I'm pegged on disk (still getting better
>> instrumentation). I would expect that my disk usage would be nearly
>> halved when striping data - still gathering info though.
>>
>> On 13-03-19 8:40 AM, "Jim Mlodgenski" <ji...@gm...> wrote:
>>
>>>It may be easier to just concentrate on the PostgreSQL test to find
>>>the bottleneck. The fact that the XC test (without GTM Proxy) and the
>>>PostgreSQL test is so similar, is leading me to believe you're hitting
>>>the same bottleneck.
>>>
>>>On Tue, Mar 19, 2013 at 11:35 AM, Chris Brown <cb...@in...>
>>>wrote:
>>>> I assume I'm I/O bound. The CPU on the datanode/coordinator/gtm_proxy
>>>>boxes gets to around 85%. I'll need some more instrumentation to be
>>>>sure - I'll get back to you with details.
>>>>
>>>> Chris...
>>>>
>>>> ________________________________________
>>>> From: Jim Mlodgenski [ji...@gm...]
>>>> Sent: March 19, 2013 8:32 AM
>>>> To: Chris Brown
>>>> Cc: pos...@li...
>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>>>
>>>> When running the test against straight PostgreSQL, where is the
>>>> bottleneck? Are you CPU bound or IO bound?
>>>>
>>>> On Tue, Mar 19, 2013 at 10:59 AM, Chris Brown <cb...@in...>
>>>>wrote:
>>>>> I also just discovered that my assumption about postgres (non xc)
>>>>>being 9.2 was incorrect:
>>>>> postgresql-server-9.1.7-1.fc16.x86_64
>>>>> Oops, sorry about the misinformation.
>>>>>
>>>>> Chris...
>>>>> ________________________________________
>>>>> From: Chris Brown [cb...@in...]
>>>>> Sent: March 19, 2013 7:45 AM
>>>>> To: Jim Mlodgenski
>>>>> Cc: pos...@li...
>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>>>>
>>>>> Hi Jim,
>>>>>
>>>>> I believe I'm doing an fsync (fdatasync) for each commit. I'm doing
>>>>>the inserts as actual inserts performed by psql. They are not batched
>>>>>- there is one insert per line and each file contains about 10,000
>>>>>inserts. This was a conscious choice since I was testing expected
>>>>>transaction rate as opposed to import rate.
>>>>>
>>>>> I haven't done much tuning to postgres. Datanodes received this:
>>>>> checkpoint_segements=32
>>>>> effective_cache_size=4GB
>>>>> shared_buffers=4GB
>>>>> random_page_cost=3.0
>>>>> For the coordinators, no tuning was done.
>>>>> For xc, I also added:
>>>>> max_prepared_transactions = 10
>>>>> gtm_host = 'localhost' # or the remote host, as appropriate on
>>>>>coordinators
>>>>> gtm_port = 6666
>>>>> Otherwise the postgresql.conf file is the default one provided by
>>>>>initdb. If I understand this, then in linux (3.1.9-1.fc16.x86_64) I
>>>>>am
>>>>>using the defaults of wal_level(minimum), fsync(on),
>>>>>wal_sync_method(fdatasync).
>>>>>
>>>>> I reran the 60 client test with explicit DISTRIBUTE BY HASH and
>>>>>MODULO, confirming the obj_MODULO and obj_HASH in the tables:
>>>>> "table_11_obj_MODULO_idx" btree ("obj_MODULO")
>>>>> It didn't make an appreciable difference (~10 seconds on a 5m50s
>>>>>test)
>>>>>which leads me to believe that the 5m50s number is slightly in error.
>>>>>
>>>>> Chris...
>>>>>
>>>>> ________________________________________
>>>>> From: Jim Mlodgenski [ji...@gm...]
>>>>> Sent: March 19, 2013 7:26 AM
>>>>> To: Chris Brown
>>>>> Cc: Koichi Suzuki; pos...@li...
>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>>>>
>>>>> Can you send along some more details of the test? I find it odd that
>>>>> in every scenario, the load times are consistent despite the change
>>>>>in
>>>>> the number of threads. Are you committing your transaction after each
>>>>> insert? If so, your limiting factor is probably the fsync to disk
>>>>> which would account for why PostgreSQL 9.2 is about the same speed as
>>>>> XC 1.0.
>>>>>
>>>>> On Tue, Mar 19, 2013 at 10:06 AM, Chris Brown <cb...@in...>
>>>>>wrote:
>>>>>> Here's a sample table:
>>>>>>
>>>>>> CREATE TABLE table_11 (
>>>>>> "part" int not null,
>>>>>> "key1" bigint not null,
>>>>>> "key2" bigint not null,
>>>>>> "col_1" varchar(23),
>>>>>> "col_2" varchar(5),
>>>>>> "col_3" varchar(32),
>>>>>> "col_4" varchar(5),
>>>>>> PRIMARY KEY(part,key1,key2)
>>>>>> );
>>>>>>
>>>>>> I guess I'm not specifying a distribution key. I assumed, perhaps
>>>>>>incorrectly, that hash on the first element of the primary key would
>>>>>>be the default. I will try a run with an explicit DISTRIBUTE BY
>>>>>>HASH(part).
>>>>>>
>>>>>> Chris...
>>>>>> ________________________________________
>>>>>> From: Koichi Suzuki [koi...@gm...]
>>>>>> Sent: March 18, 2013 10:47 PM
>>>>>> To: Chris Brown
>>>>>> Cc: pos...@li...
>>>>>> Subject: Re: [Postgres-xc-general] PG-XC Performance
>>>>>>
>>>>>> What kind of distribution did you use in your case? If all the
>>>>>> tables are replicated, all the inserts are associated with implicit
>>>>>> 2PCs. Frequently-updated tables should be distributed (hash will
>>>>>>be
>>>>>> better if the table has a suitable column).
>>>>>>
>>>>>> Regards;
>>>>>> ----------
>>>>>> Koichi Suzuki
>>>>>>
>>>>>>
>>>>>> 2013/3/19 Chris Brown <cb...@in...>:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I've been doing some performance testing of PostgreSQL-XC. My
>>>>>>>workload is
>>>>>>> all insert in this case. I was expecting PG-XC to perform worse
>>>>>>>than the
>>>>>>> alternatives but I was shocked by how much worse it was than
>>>>>>>PostgreSQL.
>>>>>>> I'm well aware that NDB has durability and features issues so I
>>>>>>>expected
>>>>>>> it to perform better - I don't consider the 0.8 to be particularly
>>>>>>> interesting. I'd like anyone's thoughts on this.
>>>>>>>
>>>>>>> Chris...
>>>>>>>
>>>>>>>
>>>>>>> Results:
>>>>>>>
>>>>>>> All results are very approximate!
>>>>>>> CPU is an estimate on the number of cores used by server processes
>>>>>>> (ndbmtd, ndb_mgmd, postgresql, gtm, gtm_proxy).
>>>>>>> TC is a comparison of (Time*CPU) using PostgreSQL as the baseline
>>>>>>>and is
>>>>>>> intended to represent a comparative CPU cost for a single insert
>>>>>>> transaction.
>>>>>>>
>>>>>>> Client PostgreSQL PostgreSQL-XC MySQL
>>>>>>>Cluster
>>>>>>> PostgreSQL-XC-2
>>>>>>> Threads Time CPU TC Time CPU TC Time
>>>>>>>CPU
>>>>>>> TC Time CPU TC
>>>>>>> 16 5m08s 4.3 cores 1.0
>>>>>>> 24 4m56s 4.6 cores 1.0 6m10s 10.7 cores 2.9
>>>>>>> 32 4m48s 4.7 cores 1.0 5m26s 11.9 cores 2.9 2m27s
>>>>>>>7.8
>>>>>>> cores 0.8
>>>>>>> 48 4m49s 4.7 cores 1.0 5m01s 12.6 cores 2.8 2m16s
>>>>>>>8.0
>>>>>>> cores 0.8 6m06s 10.2 cores 2.7
>>>>>>> 64 5m01s 13.1 cores 2.9 2m11s
>>>>>>>8.3
>>>>>>> cores 0.8 5m50s 10.5 cores 2.7
>>>>>>> 96 2m13s
>>>>>>>8.4
>>>>>>> cores 0.8
>>>>>>>
>>>>>>>
>>>>>>> Configurations:
>>>>>>>
>>>>>>> PostgreSQL:
>>>>>>> Datanodes q1
>>>>>>> Version: 9.2.x (redhat)
>>>>>>>
>>>>>>> PostgreSQL-XC:
>>>>>>> Datanodes q1-q2 (striped)
>>>>>>> Coordinators q1-q2
>>>>>>> GTM q3
>>>>>>> Version 9.1.7 (tar)
>>>>>>>
>>>>>>> PostgreSQL-XC-2:
>>>>>>> Datanodes q1-q2 (striped)
>>>>>>> Coordinators q1-q2
>>>>>>> GTM Proxy q1-q2
>>>>>>> GTM q3
>>>>>>> Version 9.1.7 (tar)
>>>>>>>
>>>>>>> MySQL Cluster:
>>>>>>> ndbmtd q1-q2 (striped)
>>>>>>> mysqld q1-q2
>>>>>>> ndb_mgmd q1
>>>>>>> Version 7.1.17 (oracle rhel 5)
>>>>>>>
>>>>>>> q1, q2, q3 are identical boxes each with:
>>>>>>> 24g ram, 1 cpu (6 cores), middle-tier raid with battery backed
>>>>>>>ram
>>>>>>>and 3
>>>>>>> platters in raid 5.
>>>>>>> They are lan local with a vlan-aware switch (I don't know which one
>>>>>>>and I
>>>>>>> didn't check to see if it was saturated).
>>>>>>>
>>>>>>>
>>>>>>> Tables & Data:
>>>>>>>
>>>>>>> 161 tables with primary key ("part" int not null, "key1" bigint not
>>>>>>>null,
>>>>>>> "key2" bigint not null). Each table has a selection of varchar
>>>>>>>columns
>>>>>>> typically less than varchar(80). All non-primary-key columns have
>>>>>>> non-unique indexes. 5.8 million rows were imported with a
>>>>>>>different
>>>>>>> number of rows to each table.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>--------------------------------------------------------------------
>>>>>>>--
>>>>>>>--------
>>>>>>> Everyone hates slow websites. So do we.
>>>>>>> Make your web apps faster with AppDynamics
>>>>>>> Download AppDynamics Lite for free today:
>>>>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>>>>> _______________________________________________
>>>>>>> Postgres-xc-general mailing list
>>>>>>> Pos...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>--
>>>>>>-------
>>>>>> Everyone hates slow websites. So do we.
>>>>>> Make your web apps faster with AppDynamics
>>>>>> Download AppDynamics Lite for free today:
>>>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>>>> _______________________________________________
>>>>>> Postgres-xc-general mailing list
>>>>>> Pos...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>>>>
>>>>>
>>>>>----------------------------------------------------------------------
>>>>>--
>>>>>------
>>>>> Everyone hates slow websites. So do we.
>>>>> Make your web apps faster with AppDynamics
>>>>> Download AppDynamics Lite for free today:
>>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>>> _______________________________________________
>>>>> Postgres-xc-general mailing list
>>>>> Pos...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>
|
43 messages has been excluded from this view by a project administrator.
