Re: [Proposal] Global temporary tables

> 2020年2月14日 下午5:19，Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> 写道：
>
>
>
> čt 30. 1. 2020 v 15:21 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com <mailto:pavel(dot)stehule(at)gmail(dot)com>> napsal:
>
>
> čt 30. 1. 2020 v 15:17 odesílatel 曾文旌(义从) <wenjing(dot)zwj(at)alibaba-inc(dot)com <mailto:wenjing(dot)zwj(at)alibaba-inc(dot)com>> napsal:
>
>
> > 2020年1月29日 下午9:48，Robert Haas <robertmhaas(at)gmail(dot)com <mailto:robertmhaas(at)gmail(dot)com>> 写道：
> >
> > On Tue, Jan 28, 2020 at 12:12 PM 曾文旌(义从) <wenjing(dot)zwj(at)alibaba-inc(dot)com <mailto:wenjing(dot)zwj(at)alibaba-inc(dot)com>> wrote:
> >>> Opinion by Pavel
> >>> + rel->rd_islocaltemp = true; <<<<<<< if this is valid, then the name of field "rd_islocaltemp" is not probably best
> >>> I renamed rd_islocaltemp
> >>
> >> I don't see any change?
> >>
> >> Rename rd_islocaltemp to rd_istemp in global_temporary_table_v8-pg13.patch
> >
> > In view of commit 6919b7e3294702adc39effd16634b2715d04f012, I think
> > that this has approximately a 0% chance of being acceptable. If you're
> > setting a field in a way that is inconsistent with the current use of
> > the field, you're probably doing it wrong, because the field has an
> > existing purpose to which new code must conform. And if you're not
> > doing that, then you don't need to rename it.
> Thank you for pointing it out.
> I've rolled back the rename.
> But I still need rd_localtemp to be true, The reason is that
> 1 GTT The GTT needs to support DML in read-only transactions ,like local temp table.
> 2 GTT does not need to hold the lock before modifying the index buffer ,also like local temp table.
>
> Please give me feedback.
>
> maybe some like
>
> rel->rd_globaltemp = true;
>
> and somewhere else
>
> if (rel->rd_localtemp || rel->rd_globaltemp)
> {
> ...
> }
>
>
> I tested this patch again and I am very well satisfied with behave.
>
> what doesn't work still - TRUNCATE statement
>
> 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.

Wenjing

>
> Regards
>
> Pavel
>
>
>
> Wenjing
>
>
>
>
> >
> > --
> > Robert Haas
> > EnterpriseDB: http://www.enterprisedb.com <http://www.enterprisedb.com/>
> > The Enterprise PostgreSQL Company
>