Re: Covering GiST indexes

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Andreas Karlsson <andreas(at)proxel(dot)se>
Cc: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Covering GiST indexes
Date: 2019-01-29 06:38:41
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 29 янв. 2019 г., в 7:32, Andreas Karlsson <andreas(at)proxel(dot)se> написал(а):
> On 1/28/19 7:26 PM, Andrey Borodin wrote:
>>> * I am no fan of the tupdesc vs truncTupdesc separation and think that it is a potential hazard, but I do not have any better suggestion right now.
>> B-tree is copying tupdesc every time they truncate tuple. We need tuple truncation a little more often: when we are doing page split, we have to form all page tuples, truncated.
>> Initially, I've optimized only this case, but this led to prepared tupledesc for truncated tuples.
>>> * There is no test case for exclusion constraints, and I feel since that is one of the more important uses we should probably have at least one such test case.
>> Actually, I did not understand this test case. Can you elaborate more on this? How included attributes should participate in exclude index? What for?
> I mean include a table like below among the tests. I feel like this is a main use case for INCLUDE.
> x int4range,
> y int,
> );

Thanks for the explanation. Added this as case 6 to index_including_gist.

>>> * Why the random noise in the diff below? I think using "(c3) INCLUDE (c4)" for both gist and rtree results in a cleaner patch.
>> I've used columns with and without opclass in INCLUDE. This led to these seemingly random changes.
> I mean the diff would be smaller as the below. It also may make sense to make both lines "(c3) INCLUDE (c1, c4)".
> CREATE TABLE tbl (c1 int,c2 int, c3 box, c4 box);
> CREATE INDEX on tbl USING brin(c1, c2) INCLUDE (c3, c4);
> CREATE INDEX on tbl USING gist(c3) INCLUDE (c4);
> CREATE INDEX on tbl USING spgist(c3) INCLUDE (c4);
> CREATE INDEX on tbl USING gin(c1, c2) INCLUDE (c3, c4);
> CREATE INDEX on tbl USING hash(c1, c2) INCLUDE (c3, c4);
> -CREATE INDEX on tbl USING rtree(c1, c2) INCLUDE (c3, c4);
> +CREATE INDEX on tbl USING rtree(c3) INCLUDE (c4);
> CREATE INDEX on tbl USING btree(c1, c2) INCLUDE (c3, c4);

I've took your version of this test and added all variations of included attributes.

PFA v7.


Best regards, Andrey Borodin.

Attachment Content-Type Size
0001-Covering-GiST-v7.patch application/octet-stream 30.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-01-29 06:42:43 Re: Delay locking partitions during query execution
Previous Message Tom Lane 2019-01-29 06:20:24 Re: Follow-up on INSERT INTO ... SET ...