"Michael Mattox" <[EMAIL PROTECTED]> writes:
> It's much slower but I appreciate you taking the time to try. I'm pretty
> new to SQL so I must admin this query is very confusing for me. I'm using
> Java Data Objects (JDO, an O/R mapping framework) but the implementation I'm
> using (Kodo) isn't s
> Finally, decided to do an ad-hoc adjustment. Try this, or (wild guess) try
> to completely eliminate the WHERE part by subselects on ms and monitorx.
>
> This may be faster, slower, or even give different results, based
> on whether
> I guessed the 1:N relationships right or not.
It's much slowe
Michael,
This whole query looks like a mess to me. Since I don't know the exact model
and the table stats, I don't even try to rewrite your query, however, here
are the weak points I can think of:
* as Rod pointed out, there are more tables in WHERE that aren't in FROM.
This can be a bug, but the
Sorry, I neglected to say the version, yes I'm using Postgres 7.3.2 on
Linux.
Here's the output of explain analyze. The query typically takes 0-4 seconds
depending on the time frame. It's run very frequently especially to process
the nightly reports.
veriguard=# explain analyze select ms.averag
Is this 7.3.x? Can we see explain analyze output for the query?
On Wed, 2003-06-25 at 07:46, Michael Mattox wrote:
> I've used indexes to speed up my queries but this query escapes me. I'm
> curious if someone can suggest an index or a way to modify the query to use
> the index. The query is:
>
