Hi Tom,
Thank you for the input, you're absolutely right.
Have just executed like 10 VACUUM ANALYZE on the Price_Tbl in both
databases and now both queries use the same plan the bad one, GREAT!
Who said ignorance is bliss?? ;-)
Have just messed around with ALTER TABLE ... ALTER SET ST
Jona <[EMAIL PROTECTED]> writes:
> What worries me is that the plan is different,
Given that the estimated costs are close to the same, this is probably
just the result of small differences in the ANALYZE statistics leading
to small differences in cost estimates and thus choice of different
plans.
Thank you for the insight, any suggestion as to what table / columns I
should compare between the databases?
Cheers
Jona
Dennis Bjorklund wrote:
On Thu, 9 Jun 2005, Jona wrote:
It's the same (physical) server as well as the same PostGreSQL daemon,
so yes.
The only th
On Thu, 9 Jun 2005, Jona wrote:
> It's the same (physical) server as well as the same PostGreSQL daemon,
> so yes.
The only thing that can differ then is the statistics collected and the
amount of dead space in tables and indexes (but since you both reindex and
run vacuum full that should not be
It's the same (physical) server as well as the same PostGreSQL daemon,
so yes.
The only difference is the actual database, the test database is made
from a backup of the live database and restored onto the same PostGreSQL
server.
So if I run "show databases" in psql i get:
- test
- live
Make
Is effective_cache_size set the same on the test and live?
Jona wrote:
Thanks... have notified our sys admin of that so he can make the correct
changes.
It still doesn't explain the difference in query plans though?
I mean, it's the same database server the two instances of the same
database
Thanks... have notified our sys admin of that so he can make the correct
changes.
It still doesn't explain the difference in query plans though?
I mean, it's the same database server the two instances of the same
database is running on.
One instance (the live) just insists on doing the seq sca
Thank you for the swift reply, the following is the output of the SHOW
ALL for shared_buffers and effective_cache_size.
shared_buffers: 13384
effective_cache_size: 4000
server memory: 2GB
effective_cache_size should be 10-100x larger perhaps...
Chris
---(end of bro
Thank you for the swift reply, the following is the output of the SHOW
ALL for shared_buffers and effective_cache_size.
shared_buffers: 13384
effective_cache_size: 4000
server memory: 2GB
Please note, the databases are on the same server, it's merely 2
instances of the same database in order
On Thu, 9 Jun 2005 [EMAIL PROTECTED] wrote:
> I am continously encountering an issue with query plans that changes after
> a pg_dump / pg_restore operation has been performed.
>
> Have placed an export of the query, query plan etc. online at:
> http://213.173.234.215:8080/plan.htm in order to e
Greetings all,
I am continously encountering an issue with query plans that changes after
a pg_dump / pg_restore operation has been performed.
On the production database, PostGre refuses to use the defined indexes in
several queries however once the database has been dumped and restored
either
11 matches
Mail list logo
