In the output below, while the former SELECT query runs, the latter does not. This is because the hashing maps the ON clauses to the same shard for both distributed tables in the first SELECT query, but does not in the second one. This could give a false promise that such a query is possible, and might cause consistency problems in the future, so I'm opening an issue for it.
[local] v-naugur@postgres:9700-32761=# CREATE TABLE t0(c0 int);
CREATE TABLE
Time: 11.983 ms
[local] v-naugur@postgres:9700-32761=# CREATE TABLE t1(c0 text);
CREATE TABLE
Time: 29.283 ms
[local] v-naugur@postgres:9700-32761=# SELECT create_distributed_table('t0', 'c0');
┌──────────────────────────┐
│ create_distributed_table │
├──────────────────────────┤
│ │
└──────────────────────────┘
(1 row)
Time: 97.613 ms
[local] v-naugur@postgres:9700-32761=# SELECT create_distributed_table('t1', 'c0');
┌──────────────────────────┐
│ create_distributed_table │
├──────────────────────────┤
│ │
└──────────────────────────┘
(1 row)
Time: 235.251 ms
[local] v-naugur@postgres:9700-32761=# SELECT * from t0 JOIN t1 ON t0.c0 = 5 AND t1.c0 = 'hello';
┌────┬────┐
│ c0 │ c0 │
├────┼────┤
└────┴────┘
(0 rows)
Time: 30.860 ms
[local] v-naugur@postgres:9700-32761=# SELECT * from t0 JOIN t1 ON t0.c0 = 5 AND t1.c0 = 'hi';
ERROR: cannot perform distributed planning on this query
DETAIL: Cartesian products are currently unsupported
Time: 13.611 ms
In the output below, while the former SELECT query runs, the latter does not. This is because the hashing maps the ON clauses to the same shard for both distributed tables in the first SELECT query, but does not in the second one. This could give a false promise that such a query is possible, and might cause consistency problems in the future, so I'm opening an issue for it.