Are the commands in the examples the actual SQL commands for sharding and is the default to have them in the public namespace?<p>Ex:<p><pre><code> CREATE TABLE states (...)
-- distribute it to all workers
SELECT create_reference_table('states');
SELECT isolate_tenant_to_new_shard('table_name', tenant_id);
</code></pre>
While isolate_tenant_to_new_shard() doesn't seem like it'd clash with anything, create_reference_table() seems common enough to exist in someone's code. Why not have this in a citus schema by default?<p>> In Citus 6.1 Vacuum is now distributed and run in parallel automatically across your cluster.<p>Did VACUUM prior to 6.1 require one node in the cluster to issue locks on other nodes? If so what for? I'm not intimately familiar with how the nodes in the cluster communicate but would have figured each is acting as a standalone DB and coordinating common updates via 2PC (which means VACUUM was already distributed).
I just started learning Citus, it is a very promising product.<p>Couple of things for improvement / may be already supported.<p>1. New User records do not propagate to all the nodes - Manual Step.<p>2. New Database records do not propagate to all the nodes - Manual Step.<p>3. Materialized View with incremental refresh - Currently Postgres re-runs the query everytime there is a data change - For a table of billion records this is very inefficient.
> <i>Microservices and NoSQL get a lot of hype, but in many cases what you really want is a relational database that simply works, and can easily scale as your application data grows.</i><p>I believe this product is very threatened right now by Google's newly announce Cloud Spanner database[1]. Even with services like this that make scaling "easy", it doesn't yet make it transparent like Google is striving to do.<p>[1] <a href="https://cloudplatform.googleblog.com/2017/02/introducing-Cloud-Spanner-a-global-database-service-for-mission-critical-applications.html" rel="nofollow">https://cloudplatform.googleblog.com/2017/02/introducing-Clo...</a>