<<
I did try Fernando's way, he is right it is the most obvious. I am not 100% sure why, but it was very slow. I do have indexes on the tables, but perhaps I didn't have them perfectly right or something. The tables are fairly large (>2m rows) and the result was taking about 10  seconds, way too much.
>>

Adam,

How many of the 2m+ rows are historical data that's not queried that often?

I had a situation once where I had a single set of data tables. Most of the queries interacted with the most recent data (data that was 30 days old or less). I wound up creating a set of historical objects (tables, views, procs, functions) all prefaced with hist_. Then once a month we moved the old data out of the active table set into the _hist table set. It worked like a champ.

Just throwing my $0.02 out there.
Michael Riley
GySgt USMC (Retired)
www.zilchworks.com

Michael

>>Then once a month we moved the old data out of the active
>>table set into the _hist table set. It worked like a champ.

Definitely getting to the point of thinking over archive-type solutions like this. May well just add an "archived" boolean to the tables & set it true ... then use indexes on the archived field to ensure we can get to the non-archived data fast.

Honestly with a simple table I don't find the number of rows the issue with EDB, it is more whether there are decent indexes set up.