Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit
От | Euler Taveira de Oliveira |
---|---|
Тема | Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit |
Дата | |
Msg-id | 47D49824.9000500@timbira.com обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #3975: tsearch2 index should not bomb out of 1Mb limit (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: