2015-02-02 13:15 GMT+01:00 Andres Freund <and...@2ndquadrant.com>: > On 2015-02-02 12:24:44 +0100, Pavel Stehule wrote: > > 2015-02-02 12:04 GMT+01:00 Andres Freund <and...@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. > Greetings, > > Andres Freund > > -- > Andres Freund http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services >
