Re: Yet another fast GiST build - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: Yet another fast GiST build
Date
Msg-id 11209DA3-7E9D-4F84-8178-401FE48F239A@yandex-team.ru
Whole thread Raw
In response to Re: Yet another fast GiST build  ("Andrey M. Borodin" <x4mmm@yandex-team.ru>)
List pgsql-hackers

> 5 нояб. 2020 г., в 22:20, Justin Pryzby <pryzby@telsasoft.com> написал(а):
>
> On Thu, Nov 05, 2020 at 10:11:52PM +0500, Andrey Borodin wrote:
>> To test that functions are actually called for sorting build we should support directive sorting build like "CREATE
INDEXON A USING GIST(B) WITH(sorting=surely,and fail if not)". 
>
> Maybe you could add a DEBUG1 message for that, and include that in regression
> tests, which would then fail if sorting wasn't used.

That's a good idea. Thanks!
>
> Maybe you'd need to make it consistent by setting GUCs like work_mem /
> max_parallel_maintenance_workers / ??
>
> Similar to this
>
> postgres=# SET client_min_messages =debug;
> postgres=# CREATE INDEX ON A USING GIST(i) WITH(buffering=off);
> DEBUG:  building index "a_i_idx2" on table "a" serially
> CREATE INDEX

Currently, only B-tree uses parallel build, so no need to tweak GUCs except client_min_messages.
Before these tests, actually, ~20% of opclasses were not working as expected. Despite I've checked each one by hand. I
have 

PFA patch with fixed comments from Heikki.

Thanks!

Best regards, Andrey Borodin.

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module
Next
From: Tom Lane
Date:
Subject: Rethinking LOCK TABLE's behavior on views