FB 3.0 Update mit where exists durchläuft alle Record der upd tbl.

[Kostas]

Hallo Zusammen,

bei den beiden Nachstehenden Beispielen, liefert das Select auf die Rechnungen genau einen record.
Das Update aktualisiert auch nur den einen Record. Allerdings wird in beiden Beispielen die komplette Datenmenge von 500.000 Adressen durchlaufen. Das dauert natürlich. Das sehe ich auch in IBExpert unter Performance Analysis.

Code:

UPDATE ADRESSEN A
   SET A.AKTIV = 1
 WHERE EXISTS (SELECT NULL
                 FROM RECHNUNGEN R
                WHERE R.RECHNUNGSNR = 1
                  AND R.ADRESSID = A.ADRESSID
               );

oder

Code:

UPDATE ADRESSEN A
   SET A.AKTIV = 1
 WHERE A.ADRESSID IN (SELECT ADRESSID
                        FROM RECHNUNGEN R
                       WHERE R.RECHNUNGSNR = 1
                     );

Hat jemand eine Idee wie man das verhindern kann?
Ich sehr nur eine Möglichkeit über Execute Block das funktioniert auch Pfeil schnell:

Code:

EXECUTE BLOCK (IRECHNUNGSNR TYPE OF COLUMN RECHNUNGEN.RECHNUNGSNR = :RECHNUNGSNR)
AS
DECLARE VARIABLE ADRESSID TYPE OF COLUMN ADRESSEN.ADRESSID;
BEGIN
  FOR SELECT ADRESSID
        FROM RECHNUNGEN R
       WHERE R.RECHNUNGSNR = :IRECHNUNGSNR 
        INTO :ADRESSID 
  DO
  BEGIN
    UPDATE ADRESSEN A
       SET A.AKTIV = 1
     WHERE A.ADRESSID = :ADRESSID;
  END

  SUSPEND;

END

[IBExpert]

würde helfen zu wissen wie du die tabelle defininert hast und welche indizes existieren
ich vermute mal da sind keine passenden

[Uwe Raabe]

Zitat von Kostas:

Allerdings wird in beiden Beispielen die komplette Datenmenge von 500.000 Adressen durchlaufen.

Das ist aber auch nachvollziehbar: Das Exist muss ja für jeden Datensatz ausgewertet werden bevor der akzeptiert oder übersprungen werden kann.

[Kostas]

ADRESSEN.ADRESSID ist der PK.
RECHNUNGEN.ADRESSID ist ein FK auf ADRESSEN.ADRESSID.
Auf RECHNUNGEN.RECHNUNGSNR ist ein Unique Index gesetzt.

Daran liegt es somit nicht. Ich hätte erwartet, dass der Select auf die Rechnungen durchgeführt wird und die Anzahl der Results gegen den Update gefahren wird. Bei kleinen Datenmengen ist dieses Verhalten auch egal aber bei etwas größeren Datenmengen eben nicht. Im MySQL kann man ein Join für das Update einbauen. In FB geht das leider nicht.

[Uwe Raabe]

Zitat von Kostas:

Ich hätte erwartet, dass der Select auf die Rechnungen durchgeführt wird und die Anzahl der Results gegen den Update gefahren wird.

Das mag für dein zweites Code-Beispiel gelten, aber für das mit dem Exists wohl eher nicht.

Was du in dem BLOCK machst, ist ja genau das, was du erwartest. Ein ähnliches Verhalten hätte ich jetzt auch von den zweiten Code-Beispiel erwartet. Da dem offenbar nicht so ist, wäre eine Analyse der in FB verwendeten Strategie interessant. Vielleicht kann man da mit einer PLAN-Anweisung noch was tunen.

[himitsu]

Zitat von Uwe Raabe:

Zitat von Kostas:

Allerdings wird in beiden Beispielen die komplette Datenmenge von 500.000 Adressen durchlaufen.

Das ist aber auch nachvollziehbar: Das Exist muss ja für jeden Datensatz ausgewertet werden bevor der akzeptiert oder übersprungen werden kann.

Na eigentlich würde es ja reichen, wenn beim ersten Fund abgebrochen wird.
Gefunden ist gefunden und noch mehr finden ändert nichts.

exists(...)
vs
count(...) > 0

Ja, beim Count könnte man zwar auch schon beim Ersten abbrechen, aber nicht, wenn Zählen und Vergleich nicht in einer gemeinsamen optimierbaren Operation stattfinden.

count(...) > 3
könnte optimiert ja auch schon beim dritten Fund abbrechen.



Kommt also drauf an, wie das DBMS die Aufgabe löst.
* erst suchen und dann schauen, was/wieviel rauskam
* speziell suchen und dabei gleich auswerten

[Uwe Raabe]

Zitat von himitsu:

Na eigentlich würde es ja reichen, wenn beim ersten Fund abgebrochen wird.
Gefunden ist gefunden und noch mehr finden ändert nichts.

Das ist schon richtig - und das wird im SELECT-Teil wohl auch so passieren. Ändert aber nichts daran, dass trotzdem der gesamte Artikelstamm durchsucht und für jeden Datensatz das EXISTS ausgewertet wird.

[himitsu]

kommt drauf an, wie es optimiert wird
und welche Datenlage wahrscheinlicher geben ist.

* das SubSelect zu Beginn einmal auswerten dann das Exists auf diese TempTable (also mit IN)
* in jedem Durchlauf das Exists+Select neu auswerten (also mit EXISTS)

Das Eine ist besser, wenn sehr viele ADRESSEN und sehr wenige RECHNUNGEN
das Andere ist besser, wenn sehr wenige ADRESSEN und sehr viele RECHNUNGEN (was hier bestimmt wahrscheinlicher sein wird).

[Kostas]

Rows affected funktioniert bei Execute Block auch nicht oder?

[Uwe Raabe]

Könntest du den BLOCK Code nicht als Stored Procedure anlegen?