Re: Too bad performance of nested table insert operation

Hope this makes thing more clear.

> First, what other indexes are on this table? What are the definitions?
> What is the original query that is "slow" causing you to think that adding
> this index would improve anything?

There's no other indcies on this table except for the one (typestr+typelen+lookahead). Every query is executed using those columns as where predicates.  

> And... this begs the question "WHY!!!????" Is your application/query
> looking up data by these columns? Just looking at the column names, I
> would suspect not, but that is because I have no idea about your data or
> application. Normally, wouldn't you look up data by the ID+LOC and maybe
> TYPESTR, but length????

Sorry for elusive description. There's lots of things to be explained to make why such columns are indexed.

In addition, what I am talking about is not the *SELECT* operation on K0 table. What I want to improve is *INSERT* operation of procedure I've posted previously.

The main purpose of using nested purpose, again, is to save space. There are tens of thousands of rows that have the same typestr+typelen+lookahead. By saving typestr+typelen+lookahead in 3 columns and id and loc in nested table, I can save lots of space.

Currently, there are too many rows in K0. Exponentially increasing data in K0 makes it inevitable adpoting space efficient table structure.

> It looks like you are making it a lot harder than it needs to be.. While
> Oracle will let you do the nested tables, it is quite obvious that it will
> not perform as you had anticipated.
>
> Sometime (most times???) it is better to use the KISS principle (Keep It
> Simple Stupid)
>
> Michael Austin.

Thank you for your opinion; especially, KISS. I am performing this stuff based on research interest. Hope anybody can solve my problem.

Thanks.

Minkoo Seo Received on Thu May 27 2004 - 01:15:03 CDT