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
(fromshared 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
