Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Index greater than 8k

From: Darcy Buskermolen <darcyb(at)commandprompt(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, PgSQL General <pgsql-general(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Index greater than 8k
Date: 2006-10-31 16:14:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
On October 31, 2006 06:42 am, Joshua D. Drake wrote:
> Teodor Sigaev wrote:
> >> The problem I am after is the 8k index size issue. It is very easy to
> >> get a GIST index (especially when using tsearch2) that is larger than
> >> that.

The problem as I remember it is pg_tgrm not tsearch2 directly, I've sent a 
self contained test case directly to  Teodor  which shows the error. 

'ERROR:  index row requires 8792 bytes, maximum size is 8191'

> >
> > Hmm, tsearch2 GIST index  is specially designed for support huge index
> > entry:
> > first, every lexemes in tsvectore are transformed to hash value (with a
> > help of crc32), second, it's stripped all position infos, third, if size
> > of array is greater than TOAST_INDEX_TARGET then tsearch2 will make bit
> > signature of tsvector. Signature's length is fixed and equals to 252
> > bytes by default (+ 8 bytes for header of datum). All values on internal
> > pages are represented as signatures below.
> >
> > So, tsearch2 guarantees that index entry will be small enough. If it's
> > not true, then there is a bug - pls, make test suite demonstrating the
> > problem.
> >
> >> Is recompiling the block size the option there?
> >> What are the downsides, except for the custom build?
> >
> > Can you send exact error message?
> I am training this week, but Darcy can do it. Can you give them a test
> case on what we were working on with that customer?
> Joshua D. Drake

Darcy Buskermolen
Command Prompt, Inc.
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2006-10-31 16:23:40
Subject: Re: [HACKERS] WAL logging freezing
Previous:From: Tom LaneDate: 2006-10-31 16:04:55
Subject: Re: [HACKERS] WAL logging freezing

pgsql-general by date

Next:From: Tim TassonisDate: 2006-10-31 16:34:54
Subject: Re: WAL Archiving under Windows
Previous:From: Jure Lo┼żarDate: 2006-10-31 15:56:40
Subject: limit left join rows to 1

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group