ms
(28 rows)
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of John Watts
Sent: 19 May 2012 14:04
To: Tom Lane
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] difference in query plan when db is restored
Tom, thank
t=0.00..8.27 rows=1 width=23) (actual time=0.004..0.004
rows=1 loops=2947)
Index Cond: (lee.referralid = idnumber)
Total runtime: 23992.996 ms
(33 rows)
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: 18 May 2012 19:29
To: John Watts
Cc: pgsql-general@
"John Watts" writes:
> Anyone?
I'm still suspicious that you're not really re-ANALYZE'ing the relevant
tables, because there are some discrepancies in the row count estimates
that seem hard to explain otherwise, eg here:
-> Index Scan using tblcompanyindidnumber on tblcompany
(cost=0.
he
current production db...
-Original Message-
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of John Watts
Sent: 17 May 2012 22:43
To: pgsql-general@postgresql.org
Subject: [GENERAL] difference in query plan when db is restored
Hi folks,
"John Watts" writes:
> I have a database query which executes normal (under 1s) with 21 steps
> according to the query paln. However, when the database is dumped and
> restored on the _same_ PostgreSQL server, the query plan takes 34 steps
> to complete and it executes in excess of 90 seconds!
Us
Hi folks,
I have a database query which executes normal (under 1s) with 21 steps
according to the query paln. However, when the database is dumped and
restored on the _same_ PostgreSQL server, the query plan takes 34 steps
to complete and it executes in excess of 90 seconds!
Why is the query pla
No change I'm afraid :(
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: 17 May 2012 22:59
To: John Watts
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] difference in query plan when db is restored
"John Watts" writes:
> I have a da
