On 08/31/2016 09:20 PM, Vik Fearing wrote: > On 08/24/2016 06:16 PM, Robert Haas wrote: >> On Tue, Aug 23, 2016 at 6:11 PM, Tomas Vondra >> <tomas.von...@2ndquadrant.com> wrote: >>> Could someone please explain how the unlogged tables are supposed to fix the >>> catalog bloat problem, as stated in the initial patch submission? We'd still >>> need to insert/delete the catalog rows when creating/dropping the temporary >>> tables, causing the bloat. Or is there something I'm missing? >> >> No, not really. Jim just asked if the idea of partitioning the >> columns was completely dead in the water, and I said, no, you could >> theoretically salvage it. Whether that does you much good is another >> question. >> >> IMV, the point here is that you MUST have globally visible dependency >> entries for this to work sanely. If they're not in a catalog, they >> have to be someplace else, and backend-private memory isn't good >> enough, because that's not globally visible. Until we've got a >> strategy for that problem, this whole effort is going nowhere - even >> though in other respects it may be a terrific idea. > > Why not just have a regular-looking table, with a "global temporary" > relpersistence (I don't care which letter it gets) and when a backend > tries to access it, it uses its own private relfilenode instead of > whatever is in pg_class, creating one if necessary. That way the > structure of the table is fixed, with all the dependencies and whatnot, > but the content is private to each backend. What's wrong with this idea? >
It's an improvement (and it's pretty much exactly what I proposed upthread). But it does not solve the problems with pg_statistic for example (each backend needs it's own statistics. So we'd either bloat the pg_statistic (if we manage to solve the problem that the table has the same oid in all backends), or we would need in-memory tuples (just like discussed in the thread so far). -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers