From c4de02c1e6534165d2acde2b3607371a94a2fac2 Mon Sep 17 00:00:00 2001 From: Yuriy Dupyn <2153100+omedusyo@users.noreply.github.com> Date: Sun, 28 Jan 2024 22:51:27 +0100 Subject: [PATCH] Clear up division of labour --- DIVISION_OF_LABOUR.txt | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/DIVISION_OF_LABOUR.txt b/DIVISION_OF_LABOUR.txt index c7c2043..7a93f76 100644 --- a/DIVISION_OF_LABOUR.txt +++ b/DIVISION_OF_LABOUR.txt @@ -1,21 +1,19 @@ - Communication with client (mainly processing client's input) * understand and implement the postgres protocol * setup of concurrent connections - * when client sends a query, we send it to the parser "component" + * when client sends a query, we send it to the parser Parsing can be started now basically a function - String -> Result + String -> Result Validation of operation - When parsing gives you an operation, it need not make sense (e.g. table doesn't exist) - So we need to validate the operation. + When parsing gives you a raw syntax of an operation, it need not make sense (e.g. table doesn't exist) + So we need to validate it. The output of the validation is - * relevant table - * an "augmented" operation (e.g. operation with type operation) + * a proper operation validated against the database schema * reject when e.g. table doesn't exist, condition refers to non-existent column etc - * This phaze doesn't need access to rows nor indices, just table meta-data. + * This phaze doesn't need access to runtime data (e.g. rows or indices), just the table schemas. ==========Locking of tables should happen here======== @@ -30,9 +28,9 @@ Responding to the client ==========Lock on the table should be dropped here=========== Serialization/Desearilization to disk - * There are two approaches, one is incremental (and very hard) - the other is: when the server is shut down. - - - - + There are two approaches + * one is incremental (and very hard), a storage engine where you have a huge database on disk + encoding something like a BTree, and then you have a small in-memory view (cache) on what's on the disk. + And you try to constantly keep these synced. + * the other is: when the server is shut down, just serialize the in-memory database state onto disk + in e.g. JSON. Trivial to implement.