Tom,
> > Would it be best to attempt to rewrite it for IN?
> > Or, should we try to tie it in with a join?
>
> Couldn't say without a deeper understanding of what you're trying to
> accomplish.
Here are the results of each SQL rewrite.
The first pass, I rewrote it as c.id IN ():
-
LOG: dur
John Mendenhall <[EMAIL PROTECTED]> writes:
> Would it be best to attempt to rewrite it for IN?
> Or, should we try to tie it in with a join?
Couldn't say without a deeper understanding of what you're trying to
accomplish.
> BTW, what does the Materialize query plan element mean?
Means "run the
Tom,
> No, the issue is that you've got eight times as much data in the
> production server; so it's hardly surprising that it takes about
> eight times longer.
>
> The production query is spending most of its time on the subplan
> attached to the contacts table:
>
> > -> I
John Mendenhall <[EMAIL PROTECTED]> writes:
> The issue is the query plan is different, and thus,
> not up to the performance we need.
No, the issue is that you've got eight times as much data in the
production server; so it's hardly surprising that it takes about
eight times longer.
The producti
On Sat, 20 Aug 2005, John Mendenhall wrote:
> I need to improve the performance for the following
> query.
I have run the same query in the same database under
different schemas. Each schema is pretty much the same
tables and indices. One has an extra backup table and
an extra index which are n
I need to improve the performance for the following
query.
Soon after I reboot my server, the following query takes
20 seconds the first time I run it.
When I run it after that, it takes approximately 2 seconds.
I understand the caching taking place (at the os or db
level, it doesn't matter here).
