Re: Query Tuning.
- From: Vamshi Damidi <dbaprimatics@xxxxxxxxx>
- To: Greg Rahn <greg@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 28 May 2010 10:50:30 -0400
Thanks to Every one for all your ideas.
I tried Hash partitioning -- no help.
index on journalentryid -- execution plan did not pick it up
parallel ( degree 4 ) -- query came up in 40 sec.
We were expecting this query to come in some like 20 sec as we have to join
the result with some other table.
Thanks to every one once again.
Thanks,
Vamshi .D
On Sun, May 23, 2010 at 10:52 AM, Greg Rahn <greg@xxxxxxxxxxxxxxxxxx> wrote:
> TIMEID part of the select list projection( its the first column) as
> well as a GBY column.
>
> It just strikes me a very odd (e.g. poor design) that the join is not
> on TIMEID (the surrogate key) between the two tables and that there
> are no filters TIMEDIMREL, nor any other projections that would be
> used as grouping columns. Surely not your typical dimensional model
> (star schema) as I can not recall ever, in a good design, that one
> would group on the join key directly.
>
> On Sun, May 23, 2010 at 3:59 AM, Jaromir D.B. Nemec
> <jaromir@xxxxxxxxxxxx> wrote:
> > In my opinion you diagnosed the cause of the problem with this statement
> -
> > the usage of the surrogate key (TIMEID) in the time dimension.
> >
> > If I see it right, the TIMEID returned from your query in not presented
> as a
> > final result, but it is transformed to some readable information as date,
> > interval etc. in the next step.
>
> --
> Regards,
> Greg Rahn
> http://structureddata.org
>
Other related posts:
