On 07.11.2019 12:30, 曾文旌(义从) wrote:
>
>> May be the assumption is that all indexes has to be created before GTT start to be used.
> Yes, Currently, GTT's index is only supported and created in an empty table state, and other sessions are not using
it.
> There has two improvements pointer:
> 1 Index can create on GTT(A) when the GTT(A) in the current session is not empty, requiring the GTT table to be
emptyin the other session.
> Index_build needs to be done in the current session just like a normal table. This improvement is relatively easy.
>
> 2 Index can create on GTT(A) when more than one session are using this GTT(A).
> Because when I'm done creating an index of the GTT in this session and setting it to be an valid index, it's not true
forthe GTT in other sessions.
> Indexes on gtt in other sessions require "rebuild_index" before using it.
> I don't have a better solution right now, maybe you have some suggestions.
It is possible to create index on demand:
Buffer
_bt_getbuf(Relation rel, BlockNumber blkno, int access)
{
Buffer buf;
if (blkno != P_NEW)
{
/* Read an existing block of the relation */
buf = ReadBuffer(rel, blkno);
/* Session temporary relation may be not yet initialized for
this backend. */
if (blkno == BTREE_METAPAGE &&
GlobalTempRelationPageIsNotInitialized(rel, BufferGetPage(buf)))
{
Relation heap = RelationIdGetRelation(rel->rd_index->indrelid);
ReleaseBuffer(buf);
DropRelFileNodeLocalBuffers(rel->rd_node, MAIN_FORKNUM, blkno);
btbuild(heap, rel, BuildIndexInfo(rel));
RelationClose(heap);
buf = ReadBuffer(rel, blkno);
LockBuffer(buf, access);
}
else
{
LockBuffer(buf, access);
_bt_checkpage(rel, buf);
}
}
...
This code initializes B-Tree and load data in it when GTT index is
access and is not initialized yet.
It looks a little bit hacker but it works.
I also wonder why you are keeping information about GTT in shared
memory. Looks like the only information we really need to share is
table's metadata.
But it is already shared though catalog. All other GTT related
information is private to backend so I do not see reasons to place it in
shared memory.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company