Horton

Re: [Proposal] Global temporary tables

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Cc: Robert Haas <robertmhaas@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-01-30T10:10:35Z
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.

čt 30. 1. 2020 v 11:02 odesílatel Konstantin Knizhnik <
k.knizhnik@postgrespro.ru> napsal:

>
>
> On 30.01.2020 12:52, Pavel Stehule wrote:
>
>
>
> čt 30. 1. 2020 v 10:44 odesílatel Konstantin Knizhnik <
> k.knizhnik@postgrespro.ru> napsal:
>
>>
>>
>> On 30.01.2020 12:23, Pavel Stehule wrote:
>>
>>
>> Building regular index requires two kinds of lock:
>>> 1. You have to lock pg_class to make changes in system catalog.
>>> 2. You need to lock heap relation  to pervent concurrent updates while
>>> building index.
>>>
>>> GTT requires 1)  but not 2).
>>> Once backend inserts information about new index in system catalog, all
>>> other sessions may use it. pg_class lock prevents any race condition here.
>>> And building index itself doesn't affect any other backends.
>>>
>>
>> It is true. The difference for GTT, so any other sessions have to build
>> index (in your proposal) as extra operation against original plan.
>>
>> What is "index"?
>> For most parts of Postgres it is just an entry in system catalog.
>> And only executor deals with its particular implementation and content.
>>
>> My point is that if we process GTT index metadata in the same way as
>> regular index metadata,
>> then there will be no differences for the postgres between GTT and
>> regular indexes.
>> And we can provide the same behavior.
>>
>
> There should be a difference - index on regular table is created by one
> process. Same thing is not possible on GTT. So there should be a difference
> every time.
>
>
> Metadata of GTT index is also created by one process. And actual content
> of the index is not interesting for most parts of Postgres.
>
>
> You can reduce some differences, but minimally me and Robert don't feel it
> well. Starting a building index from routine, that is used for reading from
> buffer doesn't look well. I can accept some stranges, but I need to have
> feeling so it is necessary. I don't think so it is necessary in this case.
>
>
> Sorry, but "don't feel it well", "doesn't look well" looks more like
> literary criticism rather than code review;)
>

The design is subjective. I am sure, so your solution can work, like mine,
or any other. But I am not sure, so your solution is good for practical
usage.


> Yes, I agree that it is unnatural to call btindex from _bt_getbuf. But
> what can go wrong here?
>

creating index as side effect of table reading. Just the side effect too
much big.


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