Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 20 von 20

Thema: Geschwindigkeit optimieren

  1. #11
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.472

    Standard

    Zitat Zitat von BoOnOdY Beitrag anzeigen
    Also falls das hilft sind hier mal meine Views die ich benutze.

    der View call_destination ist der den ich bei dem explain aufgerufen habe


    ich hab keine Idexe, weil mein SQL buch meint, dass bei dem Typ Text, den ich für den Vergleich ja brauche kein Index funktionieren würde. Stimmt das?
    Mir ist das grad zu anstrengend, diese geschachtelten VIEWS zu durchdringen.
    Hab ja auch schon längst Feierabend ;-)
    Vielleicht zeigts Du uns mal Deine Ausgangstabellen und was Du konkret wissen willst.


    Zu den Indexen:

    Das geht schon. (aber bei String-Typen mit diversen Einschränkungen und Problemen)

    Code:
    test=*# \d foo
        Table "public.foo"
     Column | Type | Modifiers
    --------+------+-----------
     w      | text |
    Indexes:
        "idx_foo" btree (lower(w) varchar_pattern_ops)
    Der Index wurde erstellt mit:

    Code:
    test=# create index idx_foo on foo (lower(w) varchar_pattern_ops);
    CREATE INDEX

    Eine Suche nutzt nun den Index:

    Code:
    test=*# explain analyse select * from foo where lower(w) like 'help%';
                                                        QUERY PLAN
    -------------------------------------------------------------------------------------------------------------------
     Bitmap Heap Scan on foo  (cost=4.71..333.12 rows=284 width=32) (actual time=0.320..0.394 rows=17 loops=1)
       Filter: (lower(w) ~~ 'help%'::text)
       ->  Bitmap Index Scan on idx_foo  (cost=0.00..4.71 rows=284 width=0) (actual time=0.267..0.267 rows=17 loops=1)
             Index Cond: ((lower(w) ~>=~ 'help'::character varying) AND (lower(w) ~<~ 'helq'::character varying))
     Total runtime: 0.567 ms
    (5 rows)
    
    Time: 3.634 ms


    Die Tabelle enthält auch ein paar Datensätze:

    Code:
    test=*# select count(1) from foo;
     count
    -------
     56840
    (1 row)
    (aus irgend einer Wörterbuchdatei)

    Zu dem Index: schau Dir mal http://www.postgresql.org/docs/8.1/i...s-opclass.html
    an. So wirklich firm bin ich da bei Indexen auf CHAR-Spalten nicht, weil noch nie benötigt.


    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  2. #12
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.472

    Standard

    Zitat Zitat von BoOnOdY Beitrag anzeigen
    Also falls das hilft sind hier mal meine Views die ich benutze.
    Mir ist grad schwindlig.

    Dein View asr ist eine Abfrage auf call_zustande, call_alle. Diese beiden beruhen wiederrum beide
    auf call_view. Und Du prüfst auf call_zustande."location" = call_alle."location", was aber irknwie
    beides aus call_view."location" kommt.

    Diesen View nutzt Du dann mit destination, call_desti im View call_destination, wobei call_desti wieder aus destination ermittelt wird. Du erzeugst damit offensichtlich enorme Zwischenresultate.

    Mein Rat: vergesse die Views, schaue auf die originalen Tabellen und arbeite damit. Irknwie drehst Du Dich da im Kreise...


    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  3. #13
    BoOnOdY ist offline Benutzer
    Registriert seit
    15.07.2006
    Beiträge
    72

    Standard

    Ja ich dreh mich echt im Kreis.

    Ich schreib morgen ma genau und klar auf was ich eigentlich will und dann sagt ihr mir was ich falsch gemacht habe, wenn ich nicht selbst auch was finde, okay?

    Gruß BoOnOdY

  4. #14
    BoOnOdY ist offline Benutzer
    Registriert seit
    15.07.2006
    Beiträge
    72

    Standard

    Was möchte ich erreichen?
    - Ich möchte aus einer Tabelle mit folgendem Plaintext:
    Code:
    identify serial NOT NULL,
    callrefnummer text NOT NULL,
    datum date,
    uhrzeit time,
    eingangsport int4,
    ausgangsport int4,
    eingangsnummer text,
    ausgangsnummer text,
    dauer int4,
    releasecode text,
    CONSTRAINT call_pkey PRIMARY KEY (identify)
    die ausgangsnummer mit den dialcodes aus dieser Tabelle vergleichen
    Code:
     identify serial NOT NULL,
    dialcode text,
    name text,
    CONSTRAINT destination_pkey PRIMARY KEY (identify)
    dazu benutze ich diesen View
    Code:
     CREATE OR REPLACE VIEW call_desti AS 
    SELECT grouped_calls.dauer, ( SELECT destination.dialcode
    FROM destination
    WHERE grouped_calls.ausgangsnummer ~~ (destination.dialcode || '%'::text)
    ORDER BY char_length(destination.dialcode) DESC
    LIMIT 1) AS "location"
    FROM ( SELECT call.ausgangsnummer, call.dauer
    FROM call) grouped_calls;
    So weit so gut. nun habe ich alles was ich brauche :
    Die Daten aus Call, Destination und schließlich die zusammengeführten Daten aus call_desti, damit ich die Destination der Calls bestimmen kann.

    nun nützt mir eine riesige Liste natürlich nichts, ich will sie Gruppieren:

    dazu benutze ich dann

    Code:
     CREATE OR REPLACE VIEW call_destination AS 
     SELECT call_desti."location", destination.name, count(*) AS count, sum(call_desti.dauer) / 60000 AS dauer, max(asr."numeric") AS sum
       FROM destination, call_desti, asr
      WHERE destination.dialcode = call_desti."location" AND asr."location" = call_desti."location"
      GROUP BY call_desti."location", destination.name;
    Doch nun brauche ich einen etwas Komplizierteren Wert, der sich "ASR" nennt. er bedeutet einfach :
    Einträge die eine nicht leere Dauer-Zeile haben geteilt durch alle Einträge einer Destination.

    Also rechne ich diesen Wert in den restlichen views aus.
    Code:
     
    CREATE OR REPLACE VIEW asr AS 
     SELECT (call_zustande.anzahl::numeric(10,2) / call_alle.count::numeric(10,2) * 100::numeric)::numeric(10,2) AS "numeric", call_zustande."location"
       FROM call_zustande, call_alle
      WHERE call_zustande."location" = call_alle."location";
     
     
    CREATE OR REPLACE VIEW call_alle AS 
     SELECT call_view."location", count(*) AS count
       FROM call_view
      GROUP BY call_view."location";
     
    CREATE OR REPLACE VIEW call_zustande AS 
     SELECT count(*) AS anzahl, call_view."location"
       FROM call_view
      WHERE call_view.dauer > 0
      GROUP BY call_view."location";
    Ich möchte eigentlich so gut wie alle Daten von oben mitnehmen, dass heißt ich brauche eigentlich eine Tabelle in der der "View" gemacht worden ist und zwar pro Eintrag einfach die Zeile "Destination" angefügt ist und dann wäre ich sorgenfrei.
    Dann würde das alles super schnell laufen und ohne Probleme.
    Daher wollte ich ja das mit den Triggern und Prozeduren machen, also mir einfach eine Prozedur bauen die sagt:
    Wenn neue Daten eingetragen werden,
    dann mache den "View "call_desti"" und schreibe mir das Ergebnis dieses Views in eine Zeile dahinter die Destination heißt.
    so würden alle meine Felder mir zur Auswertung erhalten bleiben, und ich könnte vor allem das lästige "like" los werden, dass so lange braucht und nur noch mit
    "Where =" arbeiten und Indexen.

    So verstanden was ich meine? Ich möchte am Tag mehrere verschiedene auswertungen dieses Views machen, daher wäre mir eine ergänzte Tabelle lieber.

    Gruß BoOnOdY

  5. #15
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.472

    Standard

    Zitat Zitat von BoOnOdY Beitrag anzeigen
    Was möchte ich erreichen?

    So verstanden was ich meine? Ich möchte am Tag mehrere verschiedene auswertungen dieses Views machen, daher wäre mir eine ergänzte Tabelle lieber.

    Gruß BoOnOdY
    Etwas besser.

    Ich vermute mal, die Tabellen sind call und destination. Leider fehlt die Definition von call_view.

    Die Kosten für call_desti würden sich schon mal verringern, wenn für die Sortierung nach
    char_length(destination.dialcode) ein Index bestehen würde:

    create index idx_sort on destination (char_length(dialcode));

    (ich hab mal die Tables erzeugt und je 10.000 Testdaten reingeworfen...)
    Allerdings erzeugt dieser view wegens dem

    Code:
    FROM ( SELECT call.ausgangsnummer, call.dauer
               FROM call) grouped_calls;
    so viele Rows wie in call sind, und dazu macht er jeweils das

    Code:
    SELECT destination.dialcode
               FROM destination
              WHERE grouped_calls.ausgangsnummer ~~ (destination.dialcode || '%'::text)
              ORDER BY char_length(destination.dialcode) DESC
             LIMIT 1) AS "location"

    Bereits an diesem View hast Du quasi verloren. Ist das, was dieser View liefert, wirklich gewollt?

    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  6. #16
    BoOnOdY ist offline Benutzer
    Registriert seit
    15.07.2006
    Beiträge
    72

    Standard

    Also was will ich mit dieser Abfrage :

    Ich möchte erreichen dass ich eine Summe der Dauer und die Anzahl der Datensätze Pro identifziertem Dialcode habe.

    Also ich möchte das erreichen, was ich in call.destination abfrage.


    Meinst du, dass wenn ich gleich die Summe der Dauer nehme, anstatt die einzelnen Dauer ich Zeit spare?

  7. #17
    akretschmer ist offline Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.472

    Standard

    Zitat Zitat von BoOnOdY Beitrag anzeigen
    Also was will ich mit dieser Abfrage :

    Ich möchte erreichen dass ich eine Summe der Dauer und die Anzahl der Datensätze Pro identifziertem Dialcode habe.

    Also ich möchte das erreichen, was ich in call.destination abfrage.


    Meinst du, dass wenn ich gleich die Summe der Dauer nehme, anstatt die einzelnen Dauer ich Zeit spare?
    Ich bin auf Arbeit und hab nicht den Nerv, durch Deine Tables und Schemas zu steigen. Mir sind da bei Dir einige Dinge nicht ganz klar, z.B. mit der Gruppierung der Dialcodes etc.

    Fakt ist, daß solche Regex-Vergleiche recht teuer sind. Womöglich kommst Du besser, du untergliederst Deine Dialcodes in numerische Gruppen, um besser zusammengehöhrige Datensätze gruppieren zu können.


    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  8. #18
    BoOnOdY ist offline Benutzer
    Registriert seit
    15.07.2006
    Beiträge
    72

    Standard

    okay danke


    Und weil das ja so teuer ist werd ich ma gucken, wie ich einfach einen Trigger bauen kann, der mir meine Tabelle mit dem dialcode vervollständigt wenn ich die Daten includiere, dann wär das Zeitproblem ja schon ma Minimiert.

    Danke für alles

  9. #19
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    Da die Anfragen und Datenbankstruktur, wie akretschmer schon sagt, mittlerweile ziemlich undurchsichtig wird, wäre es nicht besser, noch mal bei Null zu starten und zu schauen, wie man das eleganter hinbekommt?

    Nur mal so als Idee ...
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  10. #20
    BoOnOdY ist offline Benutzer
    Registriert seit
    15.07.2006
    Beiträge
    72

Seite 2 von 2 ErsteErste 12

Ähnliche Themen

  1. Frage Geschwindigkeit der Suche
    Von strippenzieher im Forum Allgemeines
    Antworten: 2
    Letzter Beitrag: 26.10.2011, 15:17
  2. Postgre Geschwindigkeit?
    Von MrBubbles im Forum Allgemeines
    Antworten: 40
    Letzter Beitrag: 01.10.2010, 15:11
  3. Abfrage optimieren aber wie?
    Von spinner0815 im Forum SQL
    Antworten: 10
    Letzter Beitrag: 18.03.2010, 10:54
  4. DELETE-Befehl optimieren
    Von squirrel im Forum SQL
    Antworten: 2
    Letzter Beitrag: 09.01.2009, 12:28
  5. Optimieren
    Von mzda im Forum SQL
    Antworten: 8
    Letzter Beitrag: 07.07.2006, 16:35

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum