From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | obartunov(at)gmail(dot)com, Laurence Parry <greenreaper(at)hotmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Workaround: Planner preference for tsquery filter vs. GIN index in fast text search |
Date: | 2014-04-22 13:58:30 |
Message-ID: | 26989.1398175110@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Heikki Linnakangas <hlinnakangas(at)vmware(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew Spilich | 2014-04-22 15:12:32 | Re: Stalls on PGSemaphoreLock |
Previous Message | Souquieres Adam | 2014-04-22 10:14:00 | Query on partitioned table not using index |