On 2015-02-02 12:24:44 +0100, Pavel Stehule wrote: > 2015-02-02 12:04 GMT+01:00 Andres Freund <andres@2ndquadrant.com>: > > > 2.b - using unlogged tables for holding statistics, relfilenode, and all > > > necessary data > > > > I can't follow why that'd achieve anything? > > > > 1. Main catalogue will be stable. > 2. There is not necessary to implement new storage and it can helps with > transaction support.
The amount of complexity that'd be involved to store catalog data in a separate relation around the caches and accesses would be significant. I don't think that's a realistic option. > > > 3.c - store ephemeral metadata only in memory without MVCC > > > > I think that's not an option. That'd end up being a massive amount of > > duplication at a low rate of functionality. > > > > I don't plan to implement a storage - I expect only few functions for > store/read data from session memory context
What does it have to do with temp tables then?
it is mechanism how to store a session metadata related to global temp tables
> > I think it's more realistic way to implement is to have a separate > > 'relpersistence' setting for global temp tables. The first access to > > such one in a session (or xact if truncate on commit) copies the table > > from the _init fork. By having the backend id in all filenames (besides > > the init fork) they're unique between sessions. > > > > > If I understand well, it is similar to my fast implementation from 2008. It > works partially, because it doesn't solve other (session) property - like > relpages, reltuples and related data from pg_statistics
I'm honestly not particularly concerned about that problem. For one, we don't auto-analyze/vacuum temp tables. For another, it'd be comparatively easy to gather reltuples/relpages/stats from session local state if necessary. Those are all only accessed from a few places.
so I don't see a big differences from 3.c - all session metadata will stored in session memory.
I didn't write code, so I have not a knowledge about details.
