<<This is just about never the appropriate way to solve a performance
problem, as it will inevitably create performance problems in other
queries.
>>
In this particular example, this was done to "force" the query on the Linux
box to use the same plan as on the Windows box to prove that - once the
correct plan was chosen - the Linux box could at least MATCH the Windows
box.
That being said, I should mention this: we take certain "core" queries that
we know are essential and embed them in a plpgsql SRF's that save the
various settings, modify them as required for the query, then restore them
after the rows are returned.
Does this address the problem you mentioned?
<< What I'm wondering is whether the tables have been ANALYZEd recently,>>
This is SUPPOSED to be done after a restore - but I will verify, thanks for
the reminder.
<< and also whether there are any nondefault postgresql.conf settings in
use on the other server.>>
Definitely - this is what alerted me to the fact that there was something
suspicious. We try to optimize our memory settings (based on various tuning
docs, advice from here, and good old trial-and-error). Since the new config
had barely any changes, I knew something was wrong.
Carlo
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: November 1, 2007 5:42 PM
To: Carlo Stonebanks
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] How to avoid hashjoin and mergejoin
"Carlo Stonebanks" <stonec.register@sympatico.ca> writes:
> Still, the Linux server did not create the same, fast plan as the Windows
> server. In order to get the same plan we had to:
> set enable_hashjoin to 'off';
> set enable_mergejoin to 'off';
This is just about never the appropriate way to solve a performance
problem, as it will inevitably create performance problems in other
queries.
What I'm wondering is whether the tables have been ANALYZEd recently,
and also whether there are any nondefault postgresql.conf settings in
use on the other server.
regards, tom lane