Re: optimize this!

From: Howard J. Rogers <howardjr_at_dizwell.com>
Date: Mon, 04 Oct 2004 13:07:31 +1000
Message-ID: <4162109f$0$20578$afc38c87@news.optusnet.com.au>

Daniel Morgan wrote:

> FC wrote:
>
[snip]

>>>(replace 'x' with 'u' to respond)
>>>

>>
>>
>> Daniel,
>> I am not concerned about current table's size of course, but this table
>> could easily grow up to 1.000.000 rows or 10.000.000 rows, so I am just
>> making sure my application is scalable. Moreover this query is needed to
>> populate a drop down list, so the user should wait as little as possible
>> to get the output as this is not the only SQL query that is run to build
>> up the page.
>>
>> Flavio

> 
> You can not do what you are trying to do. As the table increases from
> 10K rows to 10M rows the plan will change too. Load the table with 10M
> rows with a realistic cardinality or forget the exercise.
> 

As I posted somewhere else, in a completely different thread, there is no need to do this these days. You could export/import table statistics from a production system that had 10,000,000 rows. Or you could use dbms_stats to fake the existence of 10,000,000 rows. But you don't actually need the 10,000,000 rows to see what the optimiser would make of them if you did have them.

Of course, the equivalence is measured in terms of execution plans, not execution times. But it's still a good way to go.

:-)
HJR Received on Sun Oct 03 2004 - 22:07:31 CDT