Re: GiST limits on contrib/cube with dimension > 100?
От | Andrey Borodin |
---|---|
Тема | Re: GiST limits on contrib/cube with dimension > 100? |
Дата | |
Msg-id | F25AFB45-DBE1-4D9D-AA4F-9D1CFE75263E@yandex-team.ru обсуждение исходный текст |
Ответ на | GiST limits on contrib/cube with dimension > 100? (Siarhei Siniak <siarheisiniak@yahoo.com>) |
Ответы |
Re: GiST limits on contrib/cube with dimension > 100?
Re: GiST limits on contrib/cube with dimension > 100? |
Список | 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 по дате отправления: