Re: ERROR: Gin doesn't support full scan due to it's awful - Mailing list pgsql-general

From Teodor Sigaev
Subject Re: ERROR: Gin doesn't support full scan due to it's awful
Date
Msg-id 44FE7BF6.8090407@sigaev.ru
Whole thread Raw
In response to Re: ERROR: Gin doesn't support full scan due to it's awful  (Charlie Savage <cfis@savagexi.com>)
Responses Re: ERROR: Gin doesn't support full scan due to it's awful  (Charlie Savage <cfis@savagexi.com>)
List pgsql-general
> 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.

--
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/

pgsql-general by date:

Previous
From: "Dawid Kuroczko"
Date:
Subject: Re: constraint -- one or the other column not null
Next
From: zeljko
Date:
Subject: Re: compressed protocol