Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit

From: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Edwin Groothuis <postgresql(at)mavetju(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit
Date: 2008-03-10 02:08:36
Message-ID: 47D49824.9000500@timbira.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs 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/

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2008-03-10 04:15:05 Re: setseed accepts bad seeds
Previous Message Yann ROBIN 2008-03-09 14:48:54 Re: BUG #4021: UUID NULL and not equal query failed

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2008-03-10 02:15:36 Re: XLogCacheByte is unused
Previous Message Tom Lane 2008-03-10 02:07:41 Re: Reduce the size of PageFreeSpaceInfo on 64bit platform