On 2013-02-23, Raymond C. Rodgers <sinful622@gmail.com> wrote:
> On 02/23/2013 05:26 AM, Tom Lane wrote:
>> A "virtual" tsvector like that is probably going to be useless for
>> searching as soon as you get a meaningful amount of data, because the
>> only way the DB can implement a search is to compute the tsvector
>> value for each table row and then examine it for the target word(s).
>> What you want is a GIST or GIN index on the contents of the tsvector.
> I think the only real advantage to using something like this would be a
> space savings in terms of storing the tsvector data, but I don't see
> that being a significant enough reason to go ahead and use this idea in
> a production situation. As mentioned [by pretty much all of us], once
> the table size is sufficiently large there would be a performance
> penalty by to_tsvector being executed on every record in the table.
Unless the plan comes out as a table scan the index will be used
instead ot to_tsvector()
When there is a table scan to_tsvector will be used instead of reading
from disk, I don't know how fast to_tsvector is compared to disk, but
usually computing a result is faster than reading it from disk.
Storing the tsvector in the table is likely to be faster only when a
tablescan is done and the table is fully cached in ram.
--
ââ 100% natural
