Re: [Proposal] Global temporary tables
曾文旌 (义从) <wenjing.zwj@alibaba-inc.com>
From: 曾文旌(义从) <wenjing.zwj@alibaba-inc.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: "Robert Haas" <robertmhaas@gmail.com>, "Tomas Vondra" <tomas.vondra@2ndquadrant.com>, "Konstantin Knizhnik" <k.knizhnik@postgrespro.ru>, "PostgreSQL Hackers" <pgsql-hackers@postgresql.org>, 蔡松露(子嘉) <zijia@taobao.com>, Cai, Le <le.cai@alibaba-inc.com>, 萧少聪(铁庵) <shaocong.xsc@alibaba-inc.com>
Date: 2020-02-16T15:16:19Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
PageAddItemExtended(): Add LP_UNUSED assertion.
- 30aaab26e521 14.0 cited
-
Remove temporary files after backend crash
- cd91de0d1795 14.0 cited
-
Fix comment in indexing.c
- 9fd2952cf492 14.0 cited
-
Fix failure to ignore leftover temp tables after a server crash.
- 6919b7e32947 9.3.0 cited
> 2020年2月15日 下午6:06,Pavel Stehule <pavel.stehule@gmail.com> 写道: > > >> postgres=# insert into foo select generate_series(1,10000); >> INSERT 0 10000 >> postgres=# \dt+ foo >> List of relations >> ┌────────┬──────┬───────┬───────┬─────────────┬────────┬─────────────┐ >> │ Schema │ Name │ Type │ Owner │ Persistence │ Size │ Description │ >> ╞════════╪══════╪═══════╪═══════╪═════════════╪════════╪═════════════╡ >> │ public │ foo │ table │ pavel │ session │ 384 kB │ │ >> └────────┴──────┴───────┴───────┴─────────────┴────────┴─────────────┘ >> (1 row) >> >> postgres=# truncate foo; >> TRUNCATE TABLE >> postgres=# \dt+ foo >> List of relations >> ┌────────┬──────┬───────┬───────┬─────────────┬───────┬─────────────┐ >> │ Schema │ Name │ Type │ Owner │ Persistence │ Size │ Description │ >> ╞════════╪══════╪═══════╪═══════╪═════════════╪═══════╪═════════════╡ >> │ public │ foo │ table │ pavel │ session │ 16 kB │ │ >> └────────┴──────┴───────┴───────┴─────────────┴───────┴─────────────┘ >> (1 row) >> >> I expect zero size after truncate. > Thanks for review. > > I can explain, I don't think it's a bug. > The current implementation of the truncated GTT retains two blocks of FSM pages. > The same is true for truncating regular tables in subtransactions. > This is an implementation that truncates the table without changing the relfilenode of the table. > > > This is not extra important feature - now this is little bit a surprise, because I was not under transaction. > > Changing relfilenode, I think, is necessary, minimally for future VACUUM FULL support. Not allowing relfilenode changes is the current limit. I think can improve on it. But ,This is a bit complicated. so I'd like to know the necessity of this improvement. Could you give me more details? > > Regards > > Pavel Stehule > > > Wenjing > >> >> Regards >> >> Pavel >> >> >> >> Wenjing >> >> >> >> >> > >> > -- >> > Robert Haas >> > EnterpriseDB: http://www.enterprisedb.com <http://www.enterprisedb.com/> >> > The Enterprise PostgreSQL Company >> >