Oppolzer - Informatik / Blog

yes, that was my idea, too.

If the result sets for (15, 16, 17) are just a little larger than for (33, 34,
35), the RID list that have to be combined during multiple index RID list union
processing may not fit in the RID pool, so the union of the RID lists can not be
finished, and the whole query has to be started all over again as a table space
scan.

We had this effect some time ago, too, when the RID pool on the subsystem was
unreasonably small.

Kind regards

Bernd



Am 02.03.2012 14:05, schrieb K.S.:
>
> I assume you get Multiple index scans as an accespath ? meaning you
> will use List prefetch. Are you hitting any RID list failures in one
> case and not in the other ?
>
> when you hit a rid list failure, DB2 switches an alternative access
> path a.k.a. table space scan.it would explain "acceptable" response
> times and bad respons times.
>
> difficult to tell without stats and access paths, but that's the first
> thing that comes to mind and the first thing I would check
>
>
> -----End Original Message-----