Re: Performance problem on 2 PG versions on same query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Tomas Vondra" <tv(at)fuzzy(dot)cz>
Cc: "Rémy-Christophe Schermesser" <rcs(at)netcosports(dot)com>, pgsql-general(at)postgresql(dot)org, "Bertrand Paquet" <bertrand(at)netcosports(dot)com>
Subject: Re: Performance problem on 2 PG versions on same query
Date: 2014-11-05 17:10:11
Message-ID: 13296.1415207411@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Tomas Vondra" <tv(at)fuzzy(dot)cz> writes:
> Dne 5 Listopad 2014, 17:31, Rmy-Christophe Schermesser napsal(a):
>> We have 2 instances of PG, one in 9.1.1 and 9.1.14. They have the same
>> data, schema, PG configuration, and are almost identical machines, same
>> number of cores and memory, but different cloud provider. The data was
>> transferred with a pg_dump/pg_restore. We ran VACUUM ANALYSE, ANALYSE, and
>> REINDEX on both machines.

> Well, the first observation is that the queries produce different results:

Yeah. Another reason to not believe that the databases contain identical
data is here:

>> -> Seq Scan on andalertsmatch am (cost=0.00..71287.87
>> rows=1064987 width=52) (actual time=0.000..1680.077 rows=1064987 loops=1)

>> -> Index Scan using andalertsmatch_a_mid_idx on andalertsmatch am
>> (cost=0.00..180798.61 rows=1173762 width=52) (actual
>> time=0.015..875294.427 rows=1826118122 loops=1)

For some reason there's over 1000 times more rows in andalertsmatch in
the 9.1.14 installation. I'm betting on a foulup somewhere in the data
dump/restore process.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tomas Vondra 2014-11-05 17:17:14 Re: Performance problem on 2 PG versions on same query
Previous Message Tomas Vondra 2014-11-05 16:59:18 Re: Performance problem on 2 PG versions on same query