Jeff Davis wrote:
> On Fri, 2009-10-23 at 09:26 +0100, Richard Huxton wrote:
>> That structure isn't exposed to the planner though, so it doesn't
>> benefit from any re-ordering the planner would normally do for normal
>> (exposed) AND/OR clauses.
>
> I don't think that explains it, because in the second plan you only see
> a single index scan with two quals:
>
> Index Cond: ((ftsbody_body_fts @@
> to_tsquery('commonterm'::text)) AND (ftsbody_body_fts @@
> to_tsquery('spellerror'::text)))
>
> So it's entirely up to GIN how to execute that.
http://www.postgresql.org/docs/8.4/static/gin-extensibility.html
Datum *extractQuery(...)
Returns an array of keys given a value to be queried; that is, query is
the value on the right-hand side of an indexable operator whose
left-hand side is the indexed column
So - that is presumably two separate arrays of keys being matched
against, and the AND means if the first fails it'll never check the second.
What I'm not sure about is if tsquery('commonterm & spellerror')
produces two sets of keys or if it just produces one.
--
Richard Huxton
Archonet Ltd
