Remove mentions of MX for now

citusdata · Oct 9, 2020 · 53020a4 · 53020a4
1 parent 13db793
commit 53020a4
Show file tree

Hide file tree

Showing 9 changed files with 8 additions and 211 deletions.
diff --git a/arch/mx.rst b/arch/mx.rst
diff --git a/articles/aggregation.rst b/articles/aggregation.rst
@@ -259,9 +259,8 @@ another table and perform a join:
 You can also perform joins in the INSERT..SELECT command, allowing you
 to create more detailed aggregations, e.g. by language.
 
-Distributed aggregation adds another tool to Citus' broad toolchest
-in dealing with big data problems. With parallel INSERT .. SELECT,
-parallel indexing, parallel querying, scaling write throughput through
-:ref:`Citus MX <mx>`, and many other features, Citus can not only
-horizontally scale your multi-tenant database, but can also unify many
-different parts of your data pipeline into one platform.
+Distributed aggregation adds another tool to Citus' broad toolchest in dealing
+with big data problems. With parallel INSERT .. SELECT, parallel indexing,
+parallel querying, and many other features, Citus can not only horizontally
+scale your multi-tenant database, but can also unify many different parts of
+your data pipeline into one platform.
diff --git a/develop/api_guc.rst b/develop/api_guc.rst
@@ -126,39 +126,6 @@ The ``node_conninfo`` setting takes effect only on newly opened connections. To
 
    Citus versions prior to 9.2.4 require a full database restart to force all connections to use the new setting.
 
-.. _override_table_visibility:
-
-citus.override_table_visibility (boolean)
-$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
-
-.. note::
-
-   This GUC has an effect on Citus MX only.
-
-Shards are stored on the worker nodes as regular tables with an identifier appended to their names. Unlike regular Citus, by default Citus MX does not show shards in the list of tables, when for instance a user runs ``\d`` in psql. However the shards can be made visible in MX by updating the GUC:
-
-.. code-block:: psql
-
-   SET citus.override_table_visibility TO FALSE;
-
-::
-
-   \d
-
-   +----------+--------------------+--------+----------+
-   | Schema   | Name               | Type   | Owner    |
-   |----------+--------------------+--------+----------|
-   | public   | test_table         | table  | citus    |
-   | public   | test_table_102041  | table  | citus    |
-   | public   | test_table_102043  | table  | citus    |
-   | public   | test_table_102045  | table  | citus    |
-   | public   | test_table_102047  | table  | citus    |
-   +----------+--------------------+--------+----------+
-
-Now the ``test_table`` shards (``test_table_<n>``) appear in the list.
-
-Another way to see the shards is by querying the :ref:`citus_shards_on_worker <worker_shards>` view.
-
 Query Statistics
 ---------------------------
 

diff --git a/develop/api_metadata.rst b/develop/api_metadata.rst
@@ -560,14 +560,13 @@ Results:
 Caveats:
 
 * The stats data is not replicated, and won't survive database crashes or failover
-* It's a coordinator node feature, with no :ref:`Citus MX <mx>` support
 * Tracks a limited number of queries, set by the ``pg_stat_statements.max`` GUC (default 5000)
 * To truncate the table, use the ``citus_stat_statements_reset()`` function
 
 Distributed Query Activity
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-With :ref:`mx` users can execute distributed queries from any node. Examining the standard Postgres `pg_stat_activity <https://www.postgresql.org/docs/current/static/monitoring-stats.html#PG-STAT-ACTIVITY-VIEW>`_ view on the coordinator won't include those worker-initiated queries. Also queries might get blocked on row-level locks on one of the shards on a worker node. If that happens then those queries would not show up in `pg_locks <https://www.postgresql.org/docs/current/static/view-pg-locks.html>`_ on the Citus coordinator node.
+In some situations, queries might get blocked on row-level locks on one of the shards on a worker node. If that happens then those queries would not show up in `pg_locks <https://www.postgresql.org/docs/current/static/view-pg-locks.html>`_ on the Citus coordinator node.
 
 Citus provides special views to watch queries and locks throughout the cluster, including shard-specific queries used internally to build results for distributed queries.
 
@@ -697,7 +696,7 @@ The ``citus_lock_waits`` view shows the situation.
    waiting_node_port                     | 5432
    blocking_node_port                    | 5432
 
-In this example the queries originated on the coordinator, but the view can also list locks between queries originating on workers (executed with Citus MX for instance).
+In this example the queries originated on the coordinator, but the view can also list locks between queries originating on workers.
 
 Tables on all Nodes
 -------------------
@@ -769,33 +768,3 @@ If pool information is present, Citus will try to use these values instead of se
 
    INSERT INTO pg_dist_poolinfo (nodeid, poolinfo)
         VALUES (1, 'host=127.0.0.1 port=5433');
-
-.. _worker_shards:
-
-Shards and Indices on MX Workers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-.. note::
-
-   The citus_shards_on_worker and citus_shard_indexes_on_worker views are relevant in Citus MX only. In the non-MX scenario they contain no rows.
-
-Worker nodes store shards as tables that are ordinarily hidden in Citus MX (see :ref:`override_table_visibility`). The easiest way to obtain information about the shards on each worker is to consult that worker's ``citus_shards_on_worker`` view. For instance, here are some shards on a worker for the distributed table ``test_table``:
-
-.. code-block:: postgres
-
-   SELECT * FROM citus_shards_on_worker ORDER BY 2;
-    Schema |        Name        | Type  | Owner
-   --------+--------------------+-------+-------
-    public | test_table_1130000 | table | citus
-    public | test_table_1130002 | table | citus
-
-Indices for shards are also hidden, but discoverable through another view, ``citus_shard_indexes_on_worker``:
-
-.. code-block:: postgres
-
-   SELECT * FROM citus_shard_indexes_on_worker ORDER BY 2;
-    Schema |        Name        | Type  | Owner |       Table
-   --------+--------------------+-------+-------+--------------------
-    public | test_index_1130000 | index | citus | test_table_1130000
-    public | test_index_1130002 | index | citus | test_table_1130002
-
diff --git a/develop/reference_ddl.rst b/develop/reference_ddl.rst
@@ -3,10 +3,6 @@
 Creating and Modifying Distributed Tables (DDL)
 ===============================================
 
-.. note::
-
-   Citus (including :ref:`mx`) requires that DDL commands be run from the coordinator node only.
-
 Creating And Distributing Tables
 --------------------------------
 

diff --git a/get_started/concepts.rst b/get_started/concepts.rst
@@ -17,10 +17,6 @@ Every cluster has one special node called the *coordinator* (the others are know
 
 For each query, the coordinator either *routes* it to a single worker node, or *parallelizes* it across several depending on whether the required data lives on a single node or multiple.  The coordinator knows how to do this by consulting its metadata tables. These Citus-specific tables track the DNS names and health of worker nodes, and the distribution of data across nodes. For more information, see our :ref:`metadata_tables`.
 
-.. note::
-
-   :ref:`mx` removes the need to send all queries through the coordinator node. With MX, users can send queries directly to any worker node, which allows both reads and writes to be scaled even more.
-
 Distributed Data
 ================
 

diff --git a/get_started/what_is_citus.rst b/get_started/what_is_citus.rst
@@ -18,7 +18,7 @@ Citus horizontally scales PostgreSQL across multiple machines using sharding and
 How Far Can Citus Scale?
 ------------------------
 
-Citus scales horizontally by adding worker nodes, vertically by upgrading workers/coordinator, and supports switching to :ref:`mx` mode if needed. In practice our customers have achieved the following scale, with room to grow even more:
+Citus scales horizontally by adding worker nodes, and vertically by upgrading workers/coordinator. In practice our customers have achieved the following scale, with room to grow even more:
 
 * `Algolia <https://www.citusdata.com/customers/algolia>`_
 

diff --git a/index.rst b/index.rst
@@ -86,7 +86,6 @@ Welcome to the documentation for Citus 9.4! Citus horizontally scales PostgreSQL
    :hidden:
 
    get_started/concepts.rst
-   arch/mx.rst
 
 .. toctree::
    :caption: Develop

diff --git a/performance/performance_tuning.rst b/performance/performance_tuning.rst
@@ -486,10 +486,3 @@ From a throughput standpoint, you can expect data ingest ratios of 250K - 2M row
   * Use a compute-optimized coordinator. For the workers choose memory-optimized boxes with a decent number of vcpus.
   * Go with a relatively small shard count, 32 should suffice but you could benchmark with 64, too.
   * Ingest data for a suitable amount of time (say 2, 4, 8, 24 hrs). Longer tests are more representative of a production setup.
-
-Citus MX (50k/s-500k/s)
-=======================
-
-Citus MX builds on the Citus extension. It gives you the ability to query and write to distributed tables from any node, which allows you to horizontally scale out your write-throughput using PostgreSQL. It also removes the need to interact with a primary node in a Citus cluster for data ingest or queries.
-
-Citus MX is available in Citus Enterprise Edition. For more information see :ref:`mx`.