chore: remove metastore client cruft (#2878)

crates/catalog/src/client.rs

@@ -1,55 +1,3 @@
-//! Module for facilitating interaction with the Metastore.
-//!
-//! # Architecture
-//!
-//! Communication to metastore is facilitated through a supervisor and some
-//! background tasks. Each "database" will have its own worker, and each worker
-//! will have its own copy of the GRPC client to metastore. Workers also hold a
-//! cached copy of the catalog for their respective database.
-//!
-//! When making a request to metastore, a session will send a request to the
-//! worker for the database they belong to, and the worker is responsible for
-//! translating and making the actual request to metastore.
-//!
-//! To illustrate, let's say we have three sessions for the same database:
-//!
-//! ```text
-//! Session 1 -------+
-//!                  |
-//!                  ▼
-//! Session 2 ----> Supervisor/Worker ----> Metastore (HA)
-//!                  ▲
-//!                  |
-//! Session 3 -------+
-//! ```
-//!
-//! Sessions 1, 2, and 3 all have a handle to the supervisor that allows them to
-//! submit requests to metastore like getting the updated version of a catalog
-//! or mutating a catalog. Each session will initially share a reference to the
-//! same cached catalog (Arc).
-//!
-//! When a session requests a mutation, that request is submitted to the
-//! supervisor, then to metastore itself. If metastore successfully mutates the
-//! catalog, it will return the updated catalog, and the worker will replace its
-//! cached catalog with the updated catalog. The session that made the request
-//! will get the updated catalog back from the worker. The other sessions will
-//! still have references to the old catalog until they get the updated cached
-//! catalog from the worker (which happens during the "prepare" phase of query
-//! execution).
-//!
-//! # Rationale
-//!
-//! The worker per database model helps us keep the overhead of storing cached
-//! catalogs in memory low. By having one worker per database that's responsible
-//! for making requests, we're able to store a single copy of the catalog in
-//! memory that gets shared across all sessions for a database, cutting down
-//! memory usage.
-//!
-//! Note that executing a single request at a time for a database was the
-//! easiest way to accomplish the desired catalog caching behavior, and not due
-//! to any limitations in metastore itself.
-
-
 use std::sync::atomic::{AtomicU64, Ordering};
 use std::sync::Arc;
 use std::time::Duration;

crates/metastore/src/client.rs

@@ -54,7 +54,7 @@ use std::sync::atomic::{AtomicU64, Ordering};
 use std::sync::Arc;
 use std::time::Duration;
 
-use catalog::client::{ClientRequest, MetastoreClientHandle};
+use catalog::client::{ClientRequest, MetastoreClientConfig, MetastoreClientHandle};
 use catalog::errors::CatalogError;
 use protogen::gen::metastore::service::metastore_service_client::MetastoreServiceClient;
 use protogen::gen::metastore::service::{FetchCatalogRequest, MutateRequest};
@@ -70,15 +70,6 @@ use crate::errors::Result;
 /// Number of outstanding requests per database.
 const PER_DATABASE_BUFFER: usize = 128;
 
-/// Configuration values used when starting up a worker.
-#[derive(Debug, Clone, Copy)]
-pub struct MetastoreClientConfig {
-    /// How often to fetch the latest catalog from Metastore.
-    fetch_tick_dur: Duration,
-    /// Number of ticks with no session references before the worker exits.
-    max_ticks_before_exit: usize,
-}
-
 pub const DEFAULT_METASTORE_CLIENT_CONFIG: MetastoreClientConfig = MetastoreClientConfig {
     fetch_tick_dur: Duration::from_secs(60 * 5),
     max_ticks_before_exit: 3,
@@ -103,7 +94,7 @@ impl MetastoreClientSupervisor {
     /// Create a new worker supervisor.
     pub fn new(
         client: MetastoreServiceClient<Channel>,
-        worker_conf: MetastoreClientConfig,
+        worker_conf: catalog::client::MetastoreClientConfig,
     ) -> MetastoreClientSupervisor {
         MetastoreClientSupervisor {
             workers: RwLock::new(HashMap::new()),