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

Поиск
Список
Период
Сортировка
От Kevin Flanagan
Тема Re: ERROR: GIN indexes do not support whole-index scans
Дата
Msg-id 006201caf8be$4bb52d80$e31f8880$@com
обсуждение исходный текст
Ответ на Re: ERROR: GIN indexes do not support whole-index scans  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [RFC][PATCH]: CRC32 is limiting at COPY/CTAS/INSERT ... SELECT + speeding it up
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle