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

[Charlie Savage <cfis@xxxxxxxxxxxx>]

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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature