Re: GiST limits on contrib/cube with dimension > 100? - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: GiST limits on contrib/cube with dimension > 100?
Date
Msg-id F25AFB45-DBE1-4D9D-AA4F-9D1CFE75263E@yandex-team.ru
Whole thread Raw
In response to GiST limits on contrib/cube with dimension > 100?  (Siarhei Siniak <siarheisiniak@yahoo.com>)
Responses Re: GiST limits on contrib/cube with dimension > 100?
Re: GiST limits on contrib/cube with dimension > 100?
List pgsql-hackers
Hi!

> 9 июня 2019 г., в 23:05, Siarhei Siniak <siarheisiniak@yahoo.com> написал(а):
>
> I've been using cube extension recompiled with
> #define MAX_DIM 256.
>
> But with a version 11.3 I'm getting the following error:
> failed to add item to index page in <index_name>

So, you have changed source code (removing dim constraint) and get cryptic error after that. In some way this is
expected...

Though, the reason why cube has this limit is not physical. R-tree's (cube+gist) just do not work effectively with more
than10 non-correlated dimensions. 
If you have some correlated dimensions - you, probably, should invent something more clever that just cube - plain
arrayof D*2*doubles for each tuple. 

100 is upper bound for sane data that can be indexed in case of cube...

Nevertheless, we can improve AddTuple messages. But there is not such strict guidelines as with B-tree. Probably,
tuplesshould not be bigger than half of usable page space. 

Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: alex lock
Date:
Subject: Re: set parameter for all existing session
Next
From:
Date:
Subject: RE: BEFORE UPDATE trigger on postgres_fdw table not work