On Tue, Oct 17, 2023 at 08:39:49AM +1100, Timothy Nelson wrote:
> Great! I'm not surprised it's been around a long time -- I didn't think I
> could be the only one to think of it.
>
> Thanks for the heads-up on Postgres-XL -- I'd missed that one somehow.
>
> I'm going to include the words "ar
rbitrary user-defined
code.
3. Locking is a pain. In the Postgres architecture, table locks
acquired during parse/plan have to be held through to execution,
or concurrent DDL might invalidate your plan out from under you.
We finesse that in the parallel-query case by expecting the leader
process to k
Great! I'm not surprised it's been around a long time -- I didn't think I
could be the only one to think of it.
Thanks for the heads-up on Postgres-XL -- I'd missed that one somehow.
I'm going to include the words "architecture" and "replication" so that
people searching the archives in the futu
On Mon, Oct 16, 2023 at 6:42 AM Timothy Nelson
wrote:
> I'm expecting that people will pick the idea apart, and wanted to know
> what people think of it.
>
Thanks for the proposal. This is actually a model that's been around for a
very long time. And, in fact, variations of it (e.g. parsing done
Hi all!
I'm a DevOps Manager/Engineer by trade (though the place I work is not,
unfortunately, using Postgres). I've been thinking quite a bit about what
our ideal architecture at work will look like and what scaling looks like,
both for work and for home projects (where I *am* looking at using P
