Hi Jeff,
the way I see it, is it a poor man's implementation of 'full-text' search.
I just discussed it with out navdata team and we might be redefine how do
we do the search. Regardless of that, I think that issue with Postgres
stands.
I tried now to see, how the query would behave if we always
On Wed, Jun 20, 2018 at 9:21 AM, Sasa Vilic wrote:
> Query that we have finds all routes between two set of points. A set is a
> dynamically/loosely defined by pattern given by the user input. So for
> example
> if user wants to find all routes between international airports in Austria
> toward
Hi Matthew,
thank you for query response.
There is no particular reason for using GIST instead of GIN. We only
recently discovered pg_trgm so we are new to this. What I read is that GIN
can be faster then GIST but it really depends on query and on amount of
data. Nevertheless, both index are by m
Is there a reason you used GIST on your pg_trgm indices and not GIN? In my
tests and previous posts on here, it nearly always performs worse. Also, did
you make sure if it's really SSD and set the random_page_cost accordingly?
Matthew Hall
> On Jun 20, 2018, at 8:21 AM, Sasa Vilic wrote:
>
>
Hi everyone,
we have a new query that performs badly with specific input parameters. We
get worst performance when input data is most restrictive. I have partially
identified a problem: it always happens when index scan is done in inner
loop
and index type is pg_trgm. We also noticed that for simp
