Speed ​​of loading dependent prompt

The introduction - this post contains no "how-to" approach that (yet) exist (?!). In an effort to achieve a comfortable environment for the user reports I tried to speed up loading content dependent prompt.Problem - consisting of a long response time caused by generating a list of values ​​for dependent prompt - it is hotter, the more "major" dimensions are to be promptovány. The problem will illustrate the objects to default Oracle database schema - schema oe. used metadata: Report + prompt: Problem description: When selecting a specific EMPLOYEE_ID (eg 153) in CUST_LAST_NAME dependent (Constrain = yes) prompt appears only relevant customers (Welles, Pacino, Martin Landis, Fawcett). Setting dependencies between prompts is definitely a good thing, because the end user is not bothered by irrelevant options. Any such přegenerování prompt dependent, however, persists. I tried to PROMT help speed using cache. While the following query, however, saved to the cache: When you change the EMPLOYEE_ID PROMT (and generate "similar" query) is not Cache: The second question represents a subset of the query first. According to current documentation would clearly arise should the cache-hit. So I turned to Oracle support. Describing the development of the whole communication would take many lines - at least shortly: First, I received information that this is a desirable behavior. When the voucher to the discrepancy with the documentation finally admitted that it is a mistake, but only the documentation - the "dimension-only" request for the necessary cache hit "exact-match" (in the projection and restriction of queries). The reaction thus be altered documentation. The next step was pointing out an interesting fact: If you use the same script against the XML data, the cache hit occurs as expected - suddenly "exact-match" is not needed. Finally, this request has been accepted as Bug 8541767 and was ranked 11th in the development of Release Documentation Bug was also created. but I still have doubt. That I was the first (in fact, a similar request bogged down there and was dismissed ... but even so - the second and nobody else?), Who met with this problem? So should overlook something, or know of something very'm wrong?