Re: [Proposal] Global temporary tables

曾文旌 (义从) <wenjing.zwj@alibaba-inc.com>

From: 曾文旌 <wenjing.zwj@alibaba-inc.com>
To: movead.li@highgo.ca
Cc: tushar <tushar.ahuja@enterprisedb.com>, Prabhat Sahu <prabhat.sahu@enterprisedb.com>, Pavel Stehule <pavel.stehule@gmail.com>, robertmhaas <robertmhaas@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Konstantin Knizhnik <k.knizhnik@postgrespro.ru>, pgsql-hackers <pgsql-hackers@postgresql.org>, "蔡松露(子嘉)" <zijia@taobao.com>, "Cai, Le" <le.cai@alibaba-inc.com>, wenjing <wenjing@gmail.com>, "ahsan.hadi" <ahsan.hadi@highgo.ca>
Date: 2020-08-12T09:51:41Z
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 →
  1. PageAddItemExtended(): Add LP_UNUSED assertion.

  2. Remove temporary files after backend crash

  3. Fix comment in indexing.c

  4. Fix failure to ignore leftover temp tables after a server crash.


> 2020年8月7日 下午5:30,movead.li@highgo.ca 写道:
> 
>> 
>> >I find this is the most latest mail with an attachment, so I test and reply on
>> >this thread, several points as below:
>> 
>> >1. I notice it produces new relfilenode when new session login and some
>> >data insert. But the relfilenode column in pg_class still the one when create
>> >the global temp table. I think you can try to show 0 in this area as what nail
>> >relation does. 
> >I think getting the GTT to have a default relfilenode looks closer to the existing implementation, and setting it to 0 requires extra work and has no clear benefit.
> >What do you think?
> >I'd like to know the reasons for your suggestion.
> The 'relfilenode' mean the file no on disk which different from oid of a relation,
>  the default one is a wrong for gtt, so I think it's not so good to show it in 
> pg_class.
>> 
>> >2. The nail relations handle their relfilenodes by RelMapFile struct, and this
>> >patch use hash entry and relfilenode_list, maybe RelMapFile approach more
>> >understandable in my opinion. Sorry if I miss the real design for that.
> >We can see the STORAGE and statistics info for the GTT, including relfilenode, through view pg_gtt_relstats
> 
> postgres=# \d gtt
>                 Table "public.gtt"
>  Column |  Type   | Collation | Nullable | Default 
> --------+---------+-----------+----------+---------
>  a      | integer |           |          | 
>  b      | integer |           |          | 
> 
> postgres=# insert into gtt values(1,1);
> INSERT 0 1
> postgres=# select * from pg_gtt_relstats ;
>  schemaname | tablename | relfilenode | relpages | reltuples | relallvisible | relfrozenxid | relminmxid 
> ------------+-----------+-------------+----------+-----------+---------------+--------------+------------
>  public     | gtt       |       16384 |        0 |         0 |             0 |          532 |          1
> (1 row)
> 
> postgres=# truncate gtt;
> TRUNCATE TABLE
> postgres=# select * from pg_gtt_relstats ;
>  schemaname | tablename | relfilenode | relpages | reltuples | relallvisible | relfrozenxid | relminmxid 
> ------------+-----------+-------------+----------+-----------+---------------+--------------+------------
>  public     | gtt       |       16387 |        0 |         0 |             0 |          533 |          1
> (1 row)
> 
>> 
>> I just suggest a way which maybe most naturely to the exist code struct, and it's
>> uo to you.
>> 
>> 
>> >3. I get a wrong result of pg_relation_filepath() function for global temp table,
>> >I think it's necessaryto keep this an correct output.
> 
> postgres=# select pg_relation_filepath(oid) from pg_class where relname = 'gtt';
>  pg_relation_filepath 
> ----------------------
>  base/13835/t3_16384
> (1 row)
> 
> I didn't find anything wrong. Could you please give me a demo.
> 
>> In my opinoin it should show 'base/13835/t3_16387', other than 'base/13835/t3_16384',
>> because the relfilenode change to 16387 when you truncate it in step 2.
>> 
>> >4. In gtt_search_by_relid() function, it has not handle the missing_ok argument
>> >if gtt_storage_local_hash is null. There should be some comments if it's the right
>> >code.
> >This is a problem that has been fixed in global_temporary_table_v34-pg13.patch.
> Sorry about it, I can not find it in mail thread and maybe I miss something. The mail thread
> is so long, it's better to create a new mail thread I think.

The latest status is tracked here
https://commitfest.postgresql.org/28/2349/ <https://commitfest.postgresql.org/28/2349/>

The latest patch is V35. I don't know why the patches in some of my emails are indexed, but some of them are not.



Wenjing




> 
> Regards,
> Highgo Software (Canada/China/Pakistan) 
> URL : www.highgo.ca <http://www.highgo.ca/> 
> EMAIL: mailto:movead(dot)li(at)highgo(dot)ca