From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
cc: obartunov@gmail.com, Laurence Parry <greenreaper@hotmail.com>,
 pgsql-performance@postgresql.org
Subject: Re: Workaround: Planner preference for tsquery filter vs. GIN index
 in fast text search
In-reply-to: <53560C07.80207@vmware.com>
References: <BLU178-DS1116AC5CC07E7D50A4589CA55F0@phx.gbl>
 <CAF4Au4w_th88hf9STrjATX1EW9w5xzjGXN8Mxar_E=2qc3JJcw@mail.gmail.com>
 <53560C07.80207@vmware.com>
Comments: In-reply-to Heikki Linnakangas <hlinnakangas@vmware.com>
 message dated "Tue, 22 Apr 2014 09:28:23 +0300"
Date: Tue, 22 Apr 2014 09:58:30 -0400
Message-ID: <26989.1398175110@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> On 04/20/2014 07:46 AM, Oleg Bartunov wrote:
>> btw, 9.4 should be wiser in case of rare+common terms, thanks to GIN
>> fast scan feature.

> Indeed, although we didn't actually do anything to the planner to make 
> it understand when fast scan helps.

The given query has nothing to do with rare+common terms, since there is
only one term in the search --- and what's more, the planner's estimate
for that term is spot on already (755 estimated matches vs 752 actual).

It looks to me like the complaint is more probably about inappropriate
choice of join order; but since we've been allowed to see only some small
portion of either the query or the plan, speculating about the root cause
is a fool's errand.

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance