Strange that it took > 10 minutes to reproduce it? That would almost be
consistent with the "sub-optimally executed" view?
I'm wondering whether it might be a caching thing?
It's hard without a reproducible test case. I'm just guessing what it
might be and trying to narrow down the circumstances.
On 2/05/2013 5:46 AM, Niko Paltzer wrote:
And if you re-create the view then you get the same execution plan
as running the select directly?
Yes.
Like, If you close and open the database does it speed it up?
No.
In the good select statement, it still has 2 huge table scans.
Does it really take < 1 second??
Yes.
Also, you haven't got the scan count (Explain Analyze) for the view?
I once had it and it had a scanCount of 86 million for one or two
joins. But when I tried to reproduce it, it took too long to wait at
that time (> 10 min).
Best regards, Niko
--
You received this message because you are subscribed to the Google
Groups "H2 Database" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
