Re: ERROR: Gin doesn't support full scan due to it's awful

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.
>