Hi, On 2022-02-27 06:09:54 +0100, Pavel Stehule wrote: > ne 27. 2. 2022 v 5:13 odesÃlatel Andres Freund <and...@anarazel.de> napsal: > > On 2022-02-27 04:17:52 +0100, Pavel Stehule wrote: > > > Without this, the GTT will be terribly slow like current temporary tables > > > with a lot of problems with bloating of pg_class, pg_attribute and > > > pg_depend tables. > > > > I think it's not a great idea to solve multiple complicated problems at > > once...
> I thought about this issue for a very long time, and I didn't find any > better (without more significant rewriting of pg storage). In a lot of > projects, that I know, the temporary tables are strictly prohibited due > possible devastating impact to system catalog bloat. It is a serious > problem. So any implementation of GTT should solve the questions: a) how to > reduce catalog bloating, b) how to allow session related statistics for > GTT. I agree so implementation of GTT like template based LTT (local > temporary tables) can be very simple (it is possible by extension), but > with the same unhappy performance impacts. > I don't say so current design should be accepted without any discussions > and without changes. Maybe GTT based on LTT can be better than nothing > (what we have now), and can be good enough for a lot of projects where the > load is not too high (and almost all projects have low load). I think there's just no way that it can be merged with anything close to the current design - it's unmaintainable. The need for the feature doesn't change that. That's not to say it's impossible to come up with a workable design. But it's definitely not easy. If I were to work on this - which I am not planning to - I'd try to solve the problems of "LTT" first, with an eye towards using the infrastructure for GTT. I think you'd basically have to come up with a generic design for partitioning catalog tables into local / non-local storage, without needing explicit code for each catalog. That could also be used to store the default catalog contents separately from user defined ones (e.g. pg_proc is pretty large). Greetings, Andres Freund