GiST indexes appear no longer rely on the first column - Mailing list pgsql-docs

From PG Doc comments form
Subject GiST indexes appear no longer rely on the first column
Date
Msg-id 163318014170.12519.17259277396527159302@wrigleys.postgresql.org
Whole thread Raw
List pgsql-docs
The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/14/indexes-multicolumn.html
Description:

This statement under the GiST index: "the condition on the first column is
the most important one for determining how much of the index needs to be
scanned" appears to no longer be true, at least where btree_gist is used on
all columns.

I created a table with 5 columns:

CREATE TABLE test (c1 integer,c2 integer,c3 integer,c4 integer,c5 integer)

I inserted 10 million records:

insert    into test (c1,c2,c3,c4,c5)
select    (t.v*random())::int4, (t.v*random())::int4, (t.v*random())::int4,
(t.v*random())::int4, (t.v*random())::int4
from        (select generate_series(1,10000000) v)t

Index:

create index idx_test_gist_btree on test using gist (c1, c2, c3, c4, c5);    --
requires the btree_gist extension

I then ran the following query. You can see that skipping the first column
does not appear to have a dramatic impact on performance:

select    *
from        test
--where    c1 between 999 and 1001    -- 0:0.60 GiST
--where    c1 >= 999 and c1 <= 1001    -- 0:0.66 GiST
--where    c1 in (999, 1000, 1001)        -- 0:0.81 GiST
where    c2 between 5800 and 5850    -- 0:0.91 GiST
and        c3 = 4498
and        c5 = 3036

I'm using PG 14.

pgsql-docs by date:

Previous
From: rir
Date:
Subject: small patch
Next
From: Laurenz Albe
Date:
Subject: Re: small patch