Re: index row size exceeds btree maximum, 2713 -

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: index row size exceeds btree maximum, 2713 -
Дата
Msg-id 1121720146.8208.346.camel@state.g2switchworks.com
обсуждение исходный текст
Ответ на Re: index row size exceeds btree maximum, 2713 - Solutions?  (Dan Armbrust <daniel.armbrust.list@gmail.com>)
Список pgsql-general
On Mon, 2005-07-18 at 15:17, Dan Armbrust wrote:
> We have built a Model for terminologies that we call The Lexical Grid
> (more info http://informatics.mayo.edu/LexGrid/index.php)
>
> LexGrid has multiple backend data storage mechanisms, including LDAP
> and SQL.  We do our best to remain implementation independent - our
> SQL implementations, for example can run against MS Access, DB2, MySQL
> and PostgreSQL.
>
> I'm currently trying to load a new terminology into a PosgreSQL
> backend, and arrived at this error because it happens to have a couple
> of very large data values that get mapped into the 'propertyvalue'
> field.

Well, if you're trying to maintain compatibility to multiple backends,
then requiring a non-standard block size is going to be a big
non-starter for most folks running postgresql.  Very few, if any users,
are going to be willing to install a version of postgresql setup that
way just because of one program's needs.

Does this need to be a unique index for any reason?  If so, then an
md5(propertyvalue) would give you that.  If not, then you could make a
partial index like so:

create index yada_dx on yada (propertyvalue) where
length(propertybalue)<100;

But that would require you to add "where length(propertyvalue)<100" onto
your queries to use the index, I believe.

OTOH, this may be the time to use a hash index.

В списке pgsql-general по дате отправления:

Предыдущее
От: "Guy Rouillier"
Дата:
Сообщение: Re: How to find the number of rows deleted
Следующее
От: Dan Armbrust
Дата:
Сообщение: Re: index row size exceeds btree maximum, 2713 - Solutions?