Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
От | Tom Lane |
---|---|
Тема | Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) |
Дата | |
Msg-id | 1184.1469890030@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: [Patch] Temporary tables that do not bloat pg_catalog
(a.k.a fast temp tables)
Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables) |
Список | pgsql-hackers |
Pavel Stehule <pavel.stehule@gmail.com> writes: > But there are some patterns used with work with temp tables,that should not > working, and we would to decide if we prepare workaround or not. > -- problematic pattern (old code) > IF NOT EXISTS(SELECT * FROM pg_class WHERE ....) THEN > CREATE TEMP TABLE xxx() > ELSE > TRUNCATE TABLE xxx; > END IF; > -- modern patter (new code) > BEGIN > TRUNCATE TABLE xxx; > EXCEPTION WHEN ..... THEN > CREATE TEMP TABLE(...) > END; If the former stops working, that's a sufficient reason to reject the patch: it hasn't been thought through carefully enough. The key reason why I don't think that's negotiable is that if there aren't (apparently) catalog entries corresponding to the temp tables, that will almost certainly break many things in the backend and third-party extensions, not only user code patterns like this one. We'd constantly be fielding bug reports that "feature X doesn't work with temp tables anymore". In short, I think that the way to make something like this work is to figure out how to have "virtual" catalog rows describing a temp table. Or maybe to partition the catalogs so that vacuuming away temp-table rows is easier/cheaper than today. regards, tom lane
В списке pgsql-hackers по дате отправления: