Re: ERROR: GIN indexes do not support whole-index scans - Mailing list pgsql-hackers

From Kevin Flanagan
Subject Re: ERROR: GIN indexes do not support whole-index scans
Date
Msg-id 006201caf8be$4bb52d80$e31f8880$@com
Whole thread Raw
In response to Re: ERROR: GIN indexes do not support whole-index scans  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Ah - you mentioning index definitions has suddenly made it clearer just what
that error message might mean. The source_lang_code and target_lang_code
columns didn't yet each have an index. If I create an index for either one
of them, the error then goes away, I'm guessing because the query processor
can use one index or other to filter table rows before applying the
full-text filter, rather than applying the full-text filter first then
applying the "='code'" filters to the results - which must be what the error
means you can't do.

Strange, though - if I change the "='code'" terms to use LIKE, it works ...
so it obviously can be done without adding another index. 

Still, those two columns both needed an index anyway, and everything then
works just fine, so I shan't worry about that :)

Thank you very much.

Kevin.


-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us] 
Sent: 20 May 2010 22:15
To: Kevin Flanagan
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] ERROR: GIN indexes do not support whole-index scans 

"Kevin Flanagan" <kevin-f@linkprior.com> writes:
> Why would adding "target_lang_code='en'" cause this error?

Hard to tell without seeing the index definitions for this table.
Also could we see the EXPLAIN plans for both queries?  (If possible
... I'm not sure whether you'd get this error just from EXPLAINing
the problem query.)

> Environment: PostgreSQL 8.4 on Windows (installed with one-click
installer),

8.4.what-exactly?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [RFC][PATCH]: CRC32 is limiting at COPY/CTAS/INSERT ... SELECT + speeding it up
Next
From: Florian Pflug
Date:
Subject: Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle