boolsche WHERE-Bedingungen

Naja, wann DB2 jetzt genau "pruned" habe ich auch noch nicht rausbekommen.
Bei WHERE 1 = 2 macht es es ja, bei WHERE 1 ^= 1 nicht.

Könnte u.U. daran liegen, dass a = b indexfähig ist, a ^= b aber nicht, vielleicht auch daran, dass der Filterfaktor der ersten Bedingung um einiges niedriger ist.

WHERE 1 > 2 "pruned" übrigens auch nicht, dagegen

WHERE spalte > ‚B‘ AND spalte < ‚A‘ schon.

Mehrere GET-Pages … hm, wenn Du das ganze über SPUFI/QMF… getestest hast könnte es daran liegen, dass beim ersten mal ein (aufwändiger) PREPARE gemacht wird, die nachfolgenden male das Statement aus dem DYNAMIC STATEMENT CACHE genommen wird und der PREPARE entfällt. Notfalls jedes Statement öfters absetzen und die GET PAGES vergleichen.

Bei uns ( V9-System ) kommen beide Statements übrigens auf je 16 Getpages wenn sie aus dem Cache geladen werden
… naja kommt vielleich daher, dass es einen CREATOR = ‚AA9‘ bei uns nicht gibt, verwende ich einen vorhandenen, sinds tatsächlich 5 GP mehr, allerdings auch kein SORT

Ich habe übrigens schon erlebt, dass bei derartigen Statements im Programm das komplette Statement durch den Precompiler durch eine simple SQLCODE= Zuweisung ersetzt wurde, aber auch, dass das ganze ( obwohl durch das 1=0 ziemlich sinnlos ) zur Ausführungszeit einen Tablespace-Scan verursachte. Beidemale stand in der PLAN_TABLE "PRUNED".

Verbringt DB2 denn die Zeit auch im SORT, wenn Du das ORDER BY nicht drin hast ?
Möglich wäre dann z.B. ein komplettes Scannen der SYSIBM.SYSTABLES, die durch ein List Prefetch über den Index DSNDTX01 realisiert wird ( in dem Tablespace sind ja mehrere Tabellen und segmented ist der Katalog auch nicht )

Eigentlich wollte ich noch vorschlagen, dass Du über den Monitor nachschaust, welchen Bufferpool diese zusätzlichen GPs verwenden ( in der Hoffnung, dass bei Euch Katalog und Anwenderdaten getrennte Pools verwenden ), aber die SYSIBM.SYSTABLES liegt ja auch im Katalog, so dass nicht unterscheidbar ist, ob DB2 zur Optimierung auf den Katalog zugreift, oder schon Daten der SYSTABLES liest. 

Hallo zusammen,

vielleicht kann ich mit meinen Erkenntnissen zu Erhellung beitragen:

In der Library SDSNMACS(DSN6SPRM), der Vorlage also für den DSNTIJUZ (die DSNZPARM’s) habe ich folgendes gefunden:

[tt]xxxxxxxx.SDSNMACS(DSN6SPRM)          Line 00000589 Col
Command ===>                                                  Scroll =
*   PREDPRUNE – NO OR YES. IF YES, ENABLE PK30857 OPTIMIZER   PK55076*
*               ENHANCEMENTS. DEFAULT IS NO.                         * [/tt]

Eventuell läßt sich damit die beobachtete Verhaltensweise  erklären – PK055076 – Improved Pruning of ALWAYS TRUE and ALWAYS FALSE Predicates. (for v9 fix):

Slow performance for queries with OR predicates and an always false predicate within the OR.

Examples:

[tt]WHERE ‚ABC‘ IN (‚DEF‘,’HIJ‘)
OR INDEX_COL = 123;

WHERE INDEX_COL = 123 OR 54=23;

WHERE NOT_NULL_COL IS NULL
OR INDEX_COL = 123;[/tt]

Note that not all cases of always false predicates are handled, just all literal constants and not nullable columns IS NULL.

Problem conclusion: DB2 has been fixed to better handle always false predicates under an OR context.

A new zparm PREDPRUNE is added with this APAR to enable pruning of the following types of constructs in queries:

• Predicates containing literals under an OR context that always resolve to FALSE; and
• An IS NULL predicate on a column defined as NOT NULL.

The zparm is turned off by default. The recommended setting is to take the default.

Simply applying this PTF will not change DB2 behavior. However, if you wish to enable the pruning described above, set PREDPRUNE to YES.

Gruß
Gernot