The final answer wound up being
ALTER TABLE current ALTER COLUMN orignum SET STATISTICS 100;
and then an ANALYZE current;
Then the queries started running like a champ (split seconds, not minutes).
Thanks Richard!
Rob
Richard Huxton wrote:
> Rob Schall wrote:
>> When I reanalyzed the anit
Rob Schall wrote:
I noticed the rows bit. I wasn't quite sure why it thought it would get
so many back. Even after doing a analyze. I will alter the table stats
and see if that helps.
As for the values in orignum, they are all 10 digit numbers
(nxx,npa,num). I probably could have stored them as
Rob Schall wrote:
When I reanalyzed the anitmp table with just the 4 entries (2 with
istf=true and 2 with istf=false), both queries then ran the same way/time.
So it would appear, if you want to do a join or a subselect (IN), then
the number of items if will be comparing it to must be less than a
When I reanalyzed the anitmp table with just the 4 entries (2 with
istf=true and 2 with istf=false), both queries then ran the same way/time.
So it would appear, if you want to do a join or a subselect (IN), then
the number of items if will be comparing it to must be less than a
certain number. In
Rob Schall wrote:
Question for anyone...
I have to queries. One runs in about 2 seconds. The other takes upwards
of 2 minutes. I have a temp table that is created with 2 columns. This
table is joined with the larger database of call detail records.
However, these 2 queries are handled very diffe
Question for anyone...
I have to queries. One runs in about 2 seconds. The other takes upwards
of 2 minutes. I have a temp table that is created with 2 columns. This
table is joined with the larger database of call detail records.
However, these 2 queries are handled very differently.
The queries
