-
1. Re: Materialized View incorrectly issues concurrent load query
markaddleman Mar 22, 2013 2:22 PM (in response to markaddleman)Please disregard. It turns out our client application was generating a query against both the materialized view and the underlying table. The translator saw the two queries as identical SQL and under the same request id. This condition triggered the problem in our translator that the materialized view is intended to resolve.
An interesting feature idea falls out of this case: It would be helpful to include metadata in the query as it is passed down to the translator that tracks the origin or point in the plan that generated the call. Presumably, we could have dumped this metadata and seen that the two identical queries originated from different points in the plan and that would have led us to the source of the problem more quickly.
If including this metadata all the time is too expensive, there might be a switch to turn it on.
-
2. Re: Materialized View incorrectly issues concurrent load query
shawkins Mar 25, 2013 9:08 AM (in response to markaddleman)> It would be helpful to include metadata in the query as it is passed down to the translator that tracks the origin or point in the plan that generated the call. Presumably, we could have dumped this metadata and seen that the two identical queries originated from different points in the plan and that would have led us to the source of the problem more quickly.
You could determine this from the command log.
> If including this metadata all the time is too expensive, there might be a switch to turn it on.
Perhaps that would be an option to get the query plan from the CommandContext via the ExecutionContext. However for all but trival cases it doesn't seem likely that you would want your translator to analyze plans.
Steve
-
3. Re: Materialized View incorrectly issues concurrent load query
markaddleman Mar 25, 2013 10:22 AM (in response to shawkins)You could determine this from the command log.
Good to know. Thanks
> If including this metadata all the time is too expensive, there might be a switch to turn it on.
Perhaps that would be an option to get the query plan from the CommandContext via the ExecutionContext. However for all but trival cases it doesn't seem likely that you would want your translator to analyze plans.
I was thinking a manual switch to log the necessary information but since it's already available from the command log, I think Teiid already does what we need.