On 2018-05-29 18:06:12 +0000, Nishant, Fnu wrote: > Hi, > > > To achieve this we can allocate Form_pg_class structures (for shared > > relations… a small number) on shared memory. > > But why would this be necessary / a good idea? Even if we decided it > were, it seems like it'd end up being quite invasive. But I doubt it's > a good plan, because relcache entries want / need to be updated > differently in the transaction that does the changes (as it needs to see > the effect of catalog changes before commit) than other sessions (which > only should see them after commit). > > It will be a good idea as, we can avoid maintaining file > (creation/deletion/updation) for period of engine running and we do > not need to invalidate other backend cache.
a) That's a major change. Shouldn't be considered for a bugfix. b) This is going to have locking issues / lock contention. > > Why is this good idea? > Lets take an example (assuming we have 1000 postgres backends running). > With shared memory scheme- > Operation wise, for a transaction, we allocate/free once (private > memory allocation) and memcpy data to and fro (from shared to private and > back to shared)... > Overall memory footprint 1 shared copy and 1 private only when updating. > No file creation/deletion/updation. I don't buy that nailed relations are a meaningful part of that problem. They hardly ever change. And a shared cache is a much bigger issues. Greetings, Andres Freund