Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit - Mailing list pgsql-patches

From Euler Taveira de Oliveira
Subject Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit
Date
Msg-id 47D49824.9000500@timbira.com
Whole thread Raw
In response to Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Tom Lane wrote:

> Well, there is exactly zero chance of that happening in 8.3.x, because
> the bit allocations for on-disk tsvector representation are already
> determined.  It's fairly hard to see a way of doing it in future
> releases that would have acceptable costs, either.
>
I think you missed my point or i didn't explain it in details. I'm
talking about doing the error-or-notice condition to be a guc variable
(eg ignore_tsearch_limits = on/off).

> But more to the point: no matter what the document length limit is,
> why should it be a hard error to exceed it?  The downside of not
> indexing words beyond the length limit is that searches won't find
> documents in which the search terms occur only very far into the
> document.  The downside of throwing an error is that we can't store such
> documents at all, which surely guarantees that searches won't find
> them.  How can you possibly argue that that option is better?
>
IMHO, both of the approaches are "bad"; that's why i propose an user
option. So the user can choose between to be strict (error out when it
exceeds some limit) and to relax (emit a notice when it exceeds some
limit). Maybe some day we can increase the limits (eg ts_type.h redesign).


--
   Euler Taveira de Oliveira
   http://www.timbira.com/


pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Reduce the size of PageFreeSpaceInfo on 64bit platform
Next
From: Tom Lane
Date:
Subject: Re: XLogCacheByte is unused