SPQR 3.0 Roadmap

[Denchick]

I will try to describe the desired state and what SPQR should be able to do in the next version.

Distributed tables and reference tables

There can be many tables in the database. I suggest making it easier for users who hear about SPQR for the first time to navigate through them.

• Distributed table support has already been implemented in SPQR, so let's call those tables "distributed tables".
• It can be useful to have small, rarely-changing reference tables on each shard. These tables can be read frequently, but changes to them can be made through a two-phase commit. Let's call it reference tables.
• In addition, we should provide commands like "show distributed_tables", "show reference_tables" and "show tables".

Distributed queries

We are already good at routing requests to a specific shard, now we need to work with distributed queries aka multi-shard queries.

• Simple analytical queries, which are not transactional and inconsistent, just to get an answer from all shards sometime in the future.
• Migrations or DDL commands. Let's wrap them in two-phase commit and execute on each shard. Commit If everything is ok. If there is a failure, we show an error message from each shard that has a problem. Pros: we can roll back if something goes wrong. Cons: it can be slow. Questions: what happens if the migration fails on one shard but succeeds on another?

Better psql support

• add autocompletion to psql (no idea how).
• add support for (basic) psql commands. For example, \dt.

[reshke]

* add autocompletion to psql (no idea how).

tab-completion is psql feature, meaning the only way is provide separate psql-spqr build, the way greenplum does.

* add support for (basic) psql commands. For example, `\dt`.

its meta-command, they are regular queries

[Denchick]

Better psql support
#800