From: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: WIP: parallel GiST index builds |
Date: | 2024-07-22 12:08:55 |
Message-ID: | 9CBC7FE3-22D8-4F35-A631-AECD24418004@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 22 Jul 2024, at 14:53, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>
>
>
> On 7/22/24 13:08, Andrey M. Borodin wrote:
>>
>>
>>> On 22 Jul 2024, at 12:26, Tomas Vondra
>>> <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>>>
>>> I don't understand how would that solve the problem, can you
>>> elaborate? Which of the values are you suggesting should be
>>> replaced with the shared counter? lastlsn?
>>
>> I think during build we should consider index unlogged and always use
>> GetFakeLSNForUnloggedRel() or something similar. Anyway we will
>> calllog_newpage_range(RelationGetNumberOfBlocks(index)) at the end.
>>
>
> But that doesn't update the page LSN, which GiST uses to detect
> concurrent splits, no?
During inserting tuples we need NSN on page. For NSN we can use just a counter, generated by gistGetFakeLSN() which in turn will call GetFakeLSNForUnloggedRel(). Or any other shared counter.
After inserting tuples we call log_newpage_range() to actually WAL-log pages.
All NSNs used during build must be less than LSNs used to insert new tuples after index is built.
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Karlsson | 2024-07-22 12:33:16 | Re: Special-case executor expression steps for common combinations |
Previous Message | Ashutosh Bapat | 2024-07-22 12:01:42 | Re: SQL Property Graph Queries (SQL/PGQ) |