Performance regression from QI DDL phase 1

[Mike Hanlon]

Gary Hall has described path length regression of > 10% in the Nov15 nightly build, when running the YCSB Singleton Update benchmark, and similar regressions in a wide variety of workloads. Throughput was impacted around 5% also.

Mike made him a UTT based on the Nov 14 nightly build with only the change from Ie61ce751089b57ce1894f1764c338e9400bb7b8a <https://review.trafodion.org/#/c/693/> back-ported which demonstrated that the "Query Invalidation triggered by DDL, phase 1" is responsible.

More UTTs and testing showed the problem was in the code that moves object UIDs into root tdbs -- when the table is SB_HISTOGRAMS or SB_HISTOGRAMS_INTERVALS. For these tables, getting the object UIDs requires special metadata lookups which weren't present before the change in question.

[Trafodion-Gerrit (neo-devtools)]

Fix proposed to branch: master
Review: https://review.trafodion.org/755

[Trafodion-Gerrit (neo-devtools)]

Reviewed: https://review.trafodion.org/755
Committed: https://github.com/trafodion/core/commit/4313fc292d268d99f7603af6e6884ae785c13f00
Submitter: Trafodion Jenkins
Branch: master

commit 4313fc292d268d99f7603af6e6884ae785c13f00
Author: Mike Hanlon <email address hidden>
Date: Wed Dec 3 18:02:46 2014 +0000

    Fix performance regression due to QI for DDL

    This check-in omits object UIDs from query plans for the tables
    SB_HISTOGRAMS and SB_HISTOGRAMS_INTERVALS. Previously, when the
    code generator tried to add the object UIDs for these, it had to
    make a special query to the metadata, since the corresponding
    internal cached structure omitted object UIDs when they were
    created via methods like Generator::createVirtualTableDesc. The
    special query to lookup these object UIDs was shown to be
    responsible for a large pathlengh regression.

    Change-Id: Id5046c5c55a4fc8dd2ba3f891449ea87d35a5534
    Closes-Bug: #1398600