Re: Yet another fast GiST build
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Justin Pryzby <pryzby@telsasoft.com>, Darafei Komяpa Praliaskouski <me@komzpa.net>, Pavel Borisov <pashkin.elfe@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, Michael Paquier <michael@paquier.xyz>, Alexander Korotkov <a.korotkov@postgrespro.ru>, pgsql-hackers@postgresql.org
Date: 2020-09-28T08:12:02Z
Lists: pgsql-hackers
Attachments
On 21/09/2020 17:19, Andrey M. Borodin wrote:
>> 21 сент. 2020 г., в 18:29, Andrey M. Borodin <x4mmm@yandex-team.ru> написал(а):
>>
>> It was a conscious decision with incorrect motivation. I was thinking that it will help to reduce number of "false positive" inspecting right pages. But now I see that:
>> 1. There should be no such "false positives" that we can avoid
>> 2. Valid rightlinks could help to do amcheck verification in future
>
> Well, point number 2 here is invalid. There exist one leaf page p, so that if we start traversing rightlink from p we will reach all leaf pages. But we practically have no means to find this page. This makes rightlinks not very helpful in amcheck for GiST.
Well, if you store all the right links in a hash table or something, you
can "connect the dots" after you have scanned all the pages to see that
the chain is unbroken. Probably would not be worth the trouble, since
the rightlinks are not actually needed after concurrent scans have
completed.
> But for consistency I think it worth to install them.
I agree. I did some testing with your patch. It seems that the
rightlinks are still not always set. I didn't try to debug why.
I wrote a couple of 'pageinspect' function to inspect GiST pages for
this. See attached. I then created a test table and index like this:
create table points (p point);
insert into points select point(x,y) from generate_series(-2000, 2000)
x, generate_series(-2000, 2000) y;
create index points_idx on points using gist (p);
And this is what the root page looks like:
postgres=# select * from gist_page_items(get_raw_page('points_idx', 0));
itemoffset | ctid | itemlen
------------+---------------+---------
1 | (27891,65535) | 40
2 | (55614,65535) | 40
3 | (83337,65535) | 40
4 | (97019,65535) | 40
(4 rows)
And the right links on the next level:
postgres=# select * from (VALUES (27891), (55614), (83337), (97019)) b
(blkno), lateral gist_page_opaque_info(get_raw_page('points_idx', blkno));
blkno | lsn | nsn | rightlink | flags
-------+-----+-----+------------+-------
27891 | 0/1 | 0/0 | 4294967295 | {}
55614 | 0/1 | 0/0 | 4294967295 | {}
83337 | 0/1 | 0/0 | 27891 | {}
97019 | 0/1 | 0/0 | 55614 | {}
(4 rows)
I expected there to be only one page with invalid right link, but there
are two.
- Heikki
Commits
-
Add sortsupport for gist_btree opclasses, for faster index builds.
- 9f984ba6d23d 14.0 landed
-
pageinspect: Fix relcache leak in gist_page_items().
- 04eb75e783ba 14.0 landed
-
Fix test failure with wal_level=minimal.
- 5abca4b1cd71 14.0 landed
-
Enhance nbtree index tuple deletion.
- d168b666823b 14.0 cited
-
Fix portability issues in the new gist pageinspect test.
- 6ecaaf810b8b 14.0 landed
-
Add functions to 'pageinspect' to inspect GiST indexes.
- 756ab29124d7 14.0 landed
-
Fix missing validation for the new GiST sortsupport functions.
- 6f0bc5e1daf0 14.0 landed
-
Fix compilation warning in xlog.c
- 0a3c864c3275 14.0 cited
-
Set right-links during sorted GiST index build.
- 265ea567852a 14.0 landed
-
Fix checksum calculation in the new sorting GiST build.
- c47a240fe6db 14.0 landed
-
Add support for building GiST index by sorting.
- 16fa9b2b30a3 14.0 landed