If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

 
Go Back  dBforums > Database Server Software > DB2 > Union in 2 partition table very slow

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 03-01-05, 05:42
act7656 act7656 is offline
Registered User
 
Join Date: Mar 2004
Posts: 24
Question Union in 2 partition table very slow

Hi,

I am using DB2 UDB 7.2 in Win 2K server, when i perform a UNION between 2 partition table :

Select *
from table2003

Union

Select *
from table2004

The objective i union both year table is to do a time comparison between this 2 year data to calculate some value like price change for the past 1 month, 3 month, 6 month and 1 year.

To run this query , i take very long time, the row count for each table is about 1 milion. Is there any performance tuning trick and way for me to speed up this query?
__________________
Hello
Reply With Quote
  #2 (permalink)  
Old 03-01-05, 06:43
sathyaram_s sathyaram_s is offline
Super Moderator
 
Join Date: Aug 2001
Location: UK
Posts: 4,534
Use UNION ALL instead of UNION ...

Have you considered using UNION ALL Views ... That may make your queries more efficient and scalable

Cheers
Sathyaram
__________________
Visit the new-look IDUG Website , register to gain access to the excellent content.
Reply With Quote
  #3 (permalink)  
Old 03-01-05, 19:42
jacampbell jacampbell is offline
Registered User
 
Join Date: Jan 2005
Posts: 191
While using UNION ALL will speed up the query, I wonder if it will speed up the overall process. I presume you'll end up doing something like accumulating data over date ranges in a program and comparing as you go. That means there's probably an "order by date_col" in mix somewhere.

Why not have two cursors, one for table2003 and one for table2004? The program sucks data off one for the appropriate date range, then off the other, generates the comparisions, then goes back to sucking in data.

If you are trying to do it all in SQL, try summarising data in nested/common table expressions so that only minimal data is actually processed in the union.

How often is this going to be run. Once? If so, maybe the slow response doesn't matter. If often, maybe you need an index on the appropriate column(s).

James Campbell
Reply With Quote
  #4 (permalink)  
Old 03-01-05, 23:05
act7656 act7656 is offline
Registered User
 
Join Date: Mar 2004
Posts: 24
Hi there,

i had try using UNION ALL and order by some key, but it seems doesn't help much.

This Union job need to be done daily, i had try to populate this 2 table in a temp table , but even took me 2 hours and it still running!

if i try to index both the table, what should i do?

the table key is :

D_trade, I_Market, I_Industry, I_Sector, I_Subsector

thanks..
__________________
Hello
Reply With Quote
  #5 (permalink)  
Old 03-02-05, 00:33
jacampbell jacampbell is offline
Registered User
 
Join Date: Jan 2005
Posts: 191
So the query doesn't have an order by clause? What happens if there were no trades exactly one month ago? Without that order by clause (and I did raise the question) you must be doing some sophisticated processing.

I wonder what.

James Campbell
Reply With Quote
  #6 (permalink)  
Old 03-02-05, 02:09
act7656 act7656 is offline
Registered User
 
Join Date: Mar 2004
Posts: 24
I did do the order by like the following:

(SELECT *
FROM SIMS.$$CURR_YEAR_SECQUO
WHERE
SIMS.$$CURR_YEAR_SECQUO.I_BOARD IN ('M', 'F')
AND
SIMS.$$CURR_YEAR_SECQUO.I_TRADING_METHOD = 'AM'
AND
SIMS.$$CURR_YEAR_SECQUO.I_TRADING_TYPE = 'R'
ORDER BY
SIMS.$$CURR_YEAR_SECQUO.D_TRADE)

UNION ALL

(SELECT *
FROM SIMS.$$PREV_YEAR_SECQUO
WHERE
SIMS.$$PREV_YEAR_SECQUO.I_BOARD IN ('M', 'F')
AND
SIMS.$$PREV_YEAR_SECQUO.I_TRADING_METHOD = 'AM'
AND
SIMS.$$PREV_YEAR_SECQUO.I_TRADING_TYPE = 'R'
ORDER BY
SIMS.$$PREV_YEAR_SECQUO.D_TRADE)

But the running time still the same as i take out UNION ALL and ORDER By clause.

There is impossible there a no trade (record) for everymonth as this is a stock exchange data in the whole country.

as i mentioned before, i have to take full 2 year data as i need to compare 2 years value like the price change for the past 1 month, 3 month, 6 month and 1 year ago.


Did create index on this 2 table help in the performance bottleneck? if yes, how i can do tat?
__________________
Hello
Reply With Quote
  #7 (permalink)  
Old 03-02-05, 22:53
jacampbell jacampbell is offline
Registered User
 
Join Date: Jan 2005
Posts: 191
I'm just curious how you can be certain that there is always at least one trade in every month. Is there a stock exchange rule that requires this - even if, for some reason, trading is suspended? (Here in Australia this assumption would definitely be incorrect, I just don't know about your part of the world.)

Personally, I would calculate the starting and ending dates of each month and feed them into the selects:

select * from SIMS.$$CURR_YEAR_SECQUO
where <current predicates>
and D_TRADE between :hv-start-of-1-month-ago and :hv-end-of-1-month-ago
union
select * from SIMS.$$CURR_YEAR_SECQUO
where <current predicates>
and D_TRADE between :hv-start-of-3-month-ago and :hv-end-of-3-month-ago
union
select * from SIMS.$$CURR_YEAR_SECQUO
where <current predicates>
and D_TRADE between :hv-start-of-6-month-ago and :hv-end-of-6-month-ago
union
select * from SIMS.$$PREV_YEAR_SECQUO
where <current predicates>
and D_TRADE between :hv-start-of-1-month-ago and :hv-end-of-1-month-ago
union
select * from SIMS.$$PREV_YEAR_SECQUO
where <current predicates>
and D_TRADE between :hv-start-of-3-month-ago and :hv-end-of-3-month-ago
union
select * from SIMS.$$PREV_YEAR_SECQUO
where <current predicates>
and D_TRADE between :hv-start-of-6-month-ago and :hv-end-of-6-month-ago
union
select * from SIMS.$$PREV_YEAR_SECQUO
where <current predicates>
and D_TRADE between :hv-start-of-12-month-ago and :hv-end-of-12-month-ago
ORDER BY D_TRADE

This allows much filtering since you'll only fetch data for 4 months, not at least 12, and up to 24, as you are currently doing.

James Campbell
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On