Re: ERROR: GIN indexes do not support whole-index scans

From: "Kevin Flanagan" <kevin-f(at)linkprior(dot)com>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ERROR: GIN indexes do not support whole-index scans
Date: 2010-05-21 08:19:11
Message-ID: 006201caf8be$4bb52d80$e31f8880$@com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sss(dot)pgh(dot)pa(dot)us]
Sent: 20 May 2010 22:15
To: Kevin Flanagan
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] ERROR: GIN indexes do not support whole-index scans

"Kevin Flanagan" <kevin-f(at)linkprior(dot)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

In response to

Browse pgsql-hackers by date

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