Thanks for the clarification Teodor - it makes much more sense now.
I'd agree the error message is confusing, particularly since this works:
set enable_seqscan to on;
set enable_indexscan to off;
set enable_bitmapscan to off;
select *
from test.features
where to_tsquery('') @@ features.vector;
I see why it would now. But it would be nice if the message mentioned
the root cause of the problem - that the tsquery value does not contain
any lexemes and thus is not valid for doing a search.
Thanks,
Charlie
Teodor Sigaev wrote:
>> explain analyze
>> select *
>> from test.features
>> where to_tsquery('') @@ features.vector
>>
>> ERROR: Gin doesn't support full scan due to it's awful inefficiency
>
> Look:
> contrib_regression=# select '{1,2,3}'::int4[] @ '{}'; --contains
> ?column?
> ----------
> t
> (1 row)
>
> contrib_regression=# select '{1,2,3}'::int4[] && '{}'; --overlap
> ?column?
> ----------
> f
> (1 row)
>
> contrib_regression=# select to_tsvector('asdasd') @@ ''::tsquery;
> NOTICE: query doesn't contain lexeme(s)
> ?column?
> ----------
> f
> (1 row)
>
> Semantic of different operation with void (but not NULL) argument is
> very different. If query doesn't contain any entry (returned by
> extractQuery() index support method), then GIN, in any case, doesn't
> know what it should return: whole set of pointers or nothing. But GIN
> can't return all - it will be very-very slow, because there is a lot of
> pointers in GIN index to each table's row.
>
> It seems to me that message makes confuse about reason of error...
>
>
>
>>
>> Interestingly this works:
>>
>> explain analyze
>> select *
>> from test.features
>> where NULL @@ features.vector
>
> That is because @@ is marked as 'returns NULL on NULL input', ie index
> will not be used.
>
