| From: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> |
|---|---|
| To: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
| Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Covering SPGiST index |
| Date: | 2020-08-10 07:34:24 |
| Message-ID: | CALT9ZEGtcCEogHNg72kxTJYs_XZoEVt2Lb894-Q6gw_JRtidWQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> On a first glance the whole concept of non-multicolumn index with included
> attributes seems...well, just difficult to understand.
> But I expect for SP-GiST this must be single key with multiple included
> attributes, right?
> I couldn't find a test that checks impossibility of on 2-column SP-GiST,
> only few asserts about it. Is this checked somewhere else?
>
Yes, SpGist is by its construction a single-column index, there is no such
thing like 2-column SP-GiST yet. In the same way like original SpGist will
refuse to add a second key column, this remains after modification as well,
with exception of columns attached by INCLUDE directive. They can be
(INDEX_MAX_KEYS -1) pieces and they will not be used to create additional
index trees (as there is only one), they will be just attached to the key
tree leafs tuple.
I also little bit corrected error reporting for the case when user wants to
invoke index build with not one column. Thanks!
--
Best regards,
Pavel Borisov
Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>
| Attachment | Content-Type | Size |
|---|---|---|
| spgist-covering-0002.diff | application/octet-stream | 65.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2020-08-10 08:21:06 | Re: public schema default ACL |
| Previous Message | Masahiko Sawada | 2020-08-10 06:57:33 | Re: Unnecessary delay in streaming replication due to replay lag |