If you wish, you can view this as another primer on preparing a shard-management API. Our first step towards this goal is to create a table to store the logical to physical location mappings necessary to locate a specific shard. At minimum, this table needs to track the shard ID (shard_id), the skeleton schema the shard is based on (source_schema), the shard name itself (shard_schema), and the server where the shard resides (server_name).
Some readers may wonder where the shard_map table should reside. There's a reason we introduced the shared PostgreSQL server in the introduction to this recipe. Metadata should be stored on that central server. A combination of foreign tables and materialized views will ensure that all servers ...
