Horton

Re: [Proposal] Global temporary tables

Konstantin Knizhnik <k.knizhnik@postgrespro.ru>

View thread
From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, 曾文旌(义从) <wenjing.zwj@alibaba-inc.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, 蔡松露(子嘉) <zijia@taobao.com>, "Cai, Le" <le.cai@alibaba-inc.com>, 萧少聪(铁庵) <shaocong.xsc@alibaba-inc.com>
Date: 2020-02-03T08:08:10Z
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.


On 31.01.2020 22:38, Robert Haas wrote:
> Now, your idea is not quite as crazy as that, but it has the same
> basic problem: you can't insert code into a low-level facility that
> uses a high level facility which may in turn use and depend on that
> very same low-level facility to not be in the middle of an operation.
> If you do, it's going to break somehow.
>

Thank you for explanation.
You convinced me that building indexes from _bt_getbuf is not good idea.
What do you think about idea to check and build indexes for GTT prior to 
query execution?

In this case we do not need to patch code of all indexes - it can be 
done just in one place.
We can use build function of access method to initialize index and 
populate it with data.

So right now when building query execution plan, optimizer checks if 
index is valid.
If index belongs to GTT, it an check that first page of the index is 
initialized and if not - call build method for this index.

If building index during building query plan is not desirable, we can 
just construct list of indexes which should be checked and
perform check itself and building indexes somewhere after building plan 
but for execution of the query.

Do you seem some problems with such approach?


-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company