On Mon, May 30, 2016 at 10:53 AM, Volker Boehm wrote:
> The reason for using the similarity function in place of the '%'-operator is
> that I want to use different similarity values in one query:
>
> select name, street, zip, city
> from addresses
> where name % $1
> and stree
On Sat, May 28, 2016 at 5:38 PM, Jake Magner wrote:
> Tom Lane-2 wrote
>> Jake Magner <
>
>> jakemagner90@
>
>> > writes:
>>> I tried without doing an INSERT at all, just running the SELECT queries
>>> and
>>> the result is the same. Nested loop is chosen but is much slower.
>>
>> FWIW, I just not
On Mon, May 30, 2016 at 1:53 PM, Volker Boehm wrote:
>
> The reason for using the similarity function in place of the '%'-operator
> is that I want to use different similarity values in one query:
>
> select name, street, zip, city
> from addresses
> where name % $1
> and stre
Hello,
I'm trying to find persons in an address database where I have built
trgm-indexes on name, street, zip and city.
When I search for all four parts of the address (name, street, zip and city)
select name, street, zip, city
from addresses
where name % $1
and street % $2
> > The rowcount estimates from 9.2 seem greatly different from the 8.4 plan.
> > Did you remember to ANALYZE all the tables after migrating? Maybe there
> > were some table-specific statistics targets that you forgot to transfer
> > over? In any case, the 9.2 plan looks like garbage-in-garbage-o
> > I am just about to upgrade from PostgreSQL 8.4.20 to 9.2.15, but I'v run
> > into some huge performance issues.
>
> The rowcount estimates from 9.2 seem greatly different from the 8.4 plan.
> Did you remember to ANALYZE all the tables after migrating? Maybe there
> were some table-specific st
