Super interesting project! I have zero experience writing Postgres extensions, but I was browsing a blog post about an extension the other day. I was curious what ones workflow looked like while developing a PG extension. From the little I read, it looked like you would have to recompile postgres, including your extension, then enable it just to run it. Seems like a very long feedback loop. Was I missing something?
You don't need to recompile it actually! It's enough to compile your extension and Postgres can then dynamically link to it, which makes for a perfectly good feedback loop. pgfdb is built with pgrx: https://github.com/pgcentralfoundation/pgrx, which is a framework for building Postgres extensions in Rust that handles all the compiling and linking for you. Highly recommend that if you want to try writing extensions and are also a fan of Rust!
How do table access methods work with standard PG concepts such as the shared_buffers cache? Is that irrelevant since data is stored in FDB? Also, how do the deployment semantics of FDB affect this. If I remember correctly, you typically run one FDB process per CPU on a machine. How do PG processes map to those?
A table access method can decide itself if it wants to use the PG buffer cache, pgfdb does not so it's irrelevant in that case.
> Also, how do the deployment semantics of FDB affect this. If I remember correctly, you typically run one FDB process per CPU on a machine. How do PG processes map to those
You would run the two separately, so PG processes would run and scale separately from FDB processes. Postgres spawns a new process for each connection so you would not want to map Postgres itself 1:1 with CPUs!
