By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,333 Members | 1,226 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,333 IT Pros & Developers. It's quick & easy.

Some questions on Declared Global Temp. Tables

P: n/a
Hi Folks,

1) Why do we have to commit so that statistics are taken into account :

Insert into DGTT
call ADMIN_CMD ('runstats ...')
<<- If we don't commit here, explain plans show that stats are not taken
into account for the following select.
select * from DGTT where ....

Is that correct ? If so, this always implies to have DGTT with on DELETE
PRESERVE ROWS.

2) Why can't we issue an ALTER TABLE ... VOLATILE on such tables ?

We used to do it for Not Logged Initially tables, and switching to DGTT
seems to imply "you'd better run stats".

Thanks for your help,

JM
Nov 12 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Jean,

1) Documentation states that after running RUNSTATS command "A COMMIT
should be issued to release the locks". The COMMIT is also required to
apply changes to system tables (SYSCOLUMNS, SYSTABLES, SYSCOLDIST).
Issuing a rollback is like canceling collection of the statistics.

The rest is a consequence of that.

2) I'm curious if temporary tables are optimized in the same way as
normal ones (I think not)? Would be nice to have an answer from the
lab, but I guess that VOLATILE is taken into account by default (as it
is temoprary table = table with volatile data).

Greetings, Artur

Nov 12 '05 #2

P: n/a
Artur wrote:
Jean,

1) Documentation states that after running RUNSTATS command "A COMMIT
should be issued to release the locks". The COMMIT is also required to
apply changes to system tables (SYSCOLUMNS, SYSTABLES, SYSCOLDIST).
Issuing a rollback is like canceling collection of the statistics.

The rest is a consequence of that.

2) I'm curious if temporary tables are optimized in the same way as
normal ones (I think not)? Would be nice to have an answer from the
lab, but I guess that VOLATILE is taken into account by default (as it
is temoprary table = table with volatile data).

The table is not considered volatile. The table is defined as APPEND ONLY.

There are thoughts to support ALTER TABLE VOLATILE...

Cheers
Serge

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Nov 12 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.