> Windows has CreateProcess, which isn't available elsewhere.
Yes, we still need fork() on *nix. So the solution is to reduce theoverhead of fork(). Attach to shared memory after fork() might be a
"Better shared memory management".
> This is one of the reasons for using a connection pooler like pgbouncer,
> which can vastly reduce the number of new process creations Postgres has
to do.
Yes, it’s another way I forgot to mention. But I think there should be a cleaner way without other component.
> This proposal seems moderately insane. In the first place, it
> introduces failure modes we could do without, and in the second place,
> how is it not strictly *more* expensive than what happens now? You
> still have to end up with all those TLB entries mapped in the child.
Yes, the idea is radical. But it’s practical.
1. I don’t quite catch that. Can you explain it?
2. Yes, the overall cost is still the same, but the cost can spread into multi processes thus CPUs, not 100% on Postmaster.
> (If your kernel is unable to pass down shared-memory TLBs effectively,
> ISTM that's a kernel shortcoming not a Postgres architectural problem.)
Indeed, it’s a kernel/CPUarch shortcoming. But it is also a Postgres architectural problem. MySQL and Oracle have no such problem.
IMHO Postgres should manage itself well(eg. IO/buffer pool/connection/...)
and not rely so much on OS kernel...
The fork() used to be a genius hack, but now it’s a burden and it will get
worse and worse. All I want to do is remove fork() or reduce the overhead.
Maybe *nux will have CreateProcess someday(and I think it will), and we
