On 12/30/2015 2:33 PM, Tom Lane wrote:
> Andy Colson <andy@squeakycode.net> writes:
>> On 12/30/2015 2:18 PM, Tom Lane wrote:
>>> Maybe something weird about the build you're using? What does
>>> pg_config print?
>
>> [ output ]
>
> No smoking gun there either.
>
> It might be worthwhile to update to 9.3.10, just in case there is
> something wonky about this particular build you've got. But I'm
> starting to get the feeling that you may not get an answer short
> of tracing through gincostestimate to see where it's going nuts.
>
> regards, tom lane
>
The entire database is 78Gig, would you expect a "vacuum analyze" to fix
it? I never run it.
Cuz I started one, and its still going, but at this point right now it's
preferring indexed scans. So it seems fixed.
I'd ran: analyze jasperia.search
many times, before and after I'd emailed the list. I've rebuilt the
search table several times over, but never vacuumed it.
explain analyze
select *
from jasperia.search
where search_vec @@ to_tsquery_partial('213 E 13 ST N')
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on search (cost=76.01..80.03 rows=1 width=73)
(actual time=62.803..62.804 rows=1 loops=1)
Recheck Cond: (search_vec @@
to_tsquery((array_to_string('{213,E,13,ST,N}'::text[], ' & '::text) ||
':*'::text)))
-> Bitmap Index Scan on search_key (cost=0.00..76.01 rows=1
width=0) (actual time=62.797..62.797 rows=1 loops=1)
Index Cond: (search_vec @@
to_tsquery((array_to_string('{213,E,13,ST,N}'::text[], ' & '::text) ||
':*'::text)))
Total runtime: 62.869 ms
(* The vacuum analyze is still running *)
