Actually, I did have the partitioned column in the where clause.
However, I finally did get it to work. I had to create an index on each
table for the partitioned column, even though because of the check
constraint it only could have one value! This forced the other where
clause checks to be done prior to an expensive hash step later in the
query. Thanks for your help.
> Let me correct that...it's the WHERE clause that makes the
> the column(s) that make the partition are part of the WHERE you will
> access those tables. Otherwise you're working the whole enchilada!
> Senior Data Architect / DBA
> PlanetJam Media Group
> > If you SELECT only from the columns that make the partition then
> > tables* will be accessed by the QA.
> > Since you are SELECTing from the key you are accessing *all the
> > the view...HUGE difference in performance.
> > --
> > Doo
> > Senior Data Architect / DBA
> > PlanetJam Media Group
> > > I am selecting on two columns, one is the column that the data is
> > > partitioned on and the other one has an index built on it.
> > > > Depends...if you are selecting against the columns that the
> > > > partitioned on it seems odd. If not it sounds right about
> > > > --
> > > > Doo
> > > > Senior Data Architect / DBA
> > > > PlanetJam Media Group
> > > > > I am using SQL 7.0 SP2 and am trying partitioned views for
> > > > > time. I have about 20 2 million row tables with the proper
> > > > > constraints. When I run a query directly against one of the
> > > it
> > > > > comes back in 8 seconds. When I run the same query against the
> > > > > partitioned view, it takes 1.5 minutes. I would not have
> > > such
> > > > > a large difference. Does this sound familiar to anyone?
> > > > > Sent via Deja.com
> > > > > http://www.deja.com/
> > > Sent via Deja.com
> > > http://www.deja.com/
Sent via Deja.com