Re: GiST limits on contrib/cube with dimension > 100?

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Siarhei Siniak <siarheisiniak(at)yahoo(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GiST limits on contrib/cube with dimension > 100?
Date: 2019-06-12 08:45:08
Message-ID: F25AFB45-DBE1-4D9D-AA4F-9D1CFE75263E@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!

> 9 июня 2019 г., в 23:05, Siarhei Siniak <siarheisiniak(at)yahoo(dot)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 than 10 non-correlated dimensions.
If you have some correlated dimensions - you, probably, should invent something more clever that just cube - plain array of 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, tuples should not be bigger than half of usable page space.

Best regards, Andrey Borodin.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shohei.mochizuki 2019-06-12 09:08:50 RE: BEFORE UPDATE trigger on postgres_fdw table not work
Previous Message alex lock 2019-06-12 08:30:19 Re: set parameter for all existing session