Re: TOAST issue on custom index access method

Oh,
thanks. I didn't know about index tables not having access to associated toast values. The index access method is (at
leastin the textual part) similar to GIN, however, I needed to do some changes to it. Saving the whole document is
actuallyonly important for vacuum. I think, I will find some workaround to solve this issue. 
However, it is a little bit strange, that I get toasted values (when inserting from another table) and untoasted
values,if I insert items directly. Could anybody please explain this to me? 

Best regardsCarsten Kropf
Am 24.06.2010 um 16:20 schrieb Tom Lane:

> Carsten Kropf <ckropf2@fh-hof.de> writes:
>> I have a strange issue using a custom built index structure. My index access method support document type composed
ofwords (as tsvector) and points (1-dimensional arrays of them). For internal reasons, I have to save the documents as
awhole inside my structure (for proper reorganisations). 
>> So, I form the tuples using index_form_tuple with the proper description. Everything works fine, as long as the
documentsare quite small. However, if the tsvector becomes too large, I run into a problem of not being able to store
thedocuments, because (obviously) the tsvector is too large for one page. 
>
> Well, of course.  I think this is a fundamentally bad index design.  You
> didn't say exactly what sort of searches you want this index type to
> accelerate, but perhaps you need a design closer to GIN, in which you'd
> make index entries for individual words not whole documents.
>
>> What I tried to solve this issue here, is to extract the words from the document (in my index) and calling 'Datum
toast_compress_datum(Datumvalue)'in order to compress the tsvector into a proper toast table. 
>
> Indexes don't have toast tables.
>
>             regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers