PostgreSQL "Index"

Hier dreht es sich um den PostGre Server

Moderator: Moderatoren

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Index"

Beitrag von AUGE_OHR »

hier noch eine Zeile was das REINDEX die ganze Zeit gemacht hat

Code: Alles auswählen

UPDATE fsicher SET  __rowversion=__rowversion+1,__keyversion=__rowversion,__order_fskartei_fskartei='23871TEXT @0000554952' WHERE __record=554952;
und das 554952 mal ...

Frage : geht das nicht "kürzer" ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Index"

Beitrag von AUGE_OHR »

hi,

was sollte schneller sein

Code: Alles auswählen

select * from fsicher where "fkdnr" = '11105' ORDER BY __order_fskartei_fskartei
oder

Code: Alles auswählen

select * from fsicher where "fkdnr" = '11105' ORDER BY fkdnr,fartnr
im ersten Fall wäre der "Index" __order_fskartei_fskartei = fkdnr+fartnr, also lägen "hintereinander"

im zweiten Fall erfolgt die "Sortierung" erst bei Auswahl.




















































ORDER_BY_Index.PNG
ORDER_BY_Index.PNG (38.47 KiB) 14842 mal betrachtet
ORDER_BY_Fields.PNG
ORDER_BY_Fields.PNG (40.94 KiB) 14842 mal betrachtet
beide sind gleich schnell ???
gruss by OHR
Jimmy
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: PostgreSQL "Index"

Beitrag von UliTs »

Hallo Jimmy,

Entferne am besten mal die vielen Leerzeilen :-) .
Indizes über Ausdrücke sind bei SQL nicht zu empfehlen. Diese kann der Server nur schlecht nutzen.
Besser sind Indizes über einzelne Felder oder über mehrere Felder mit Komma voneinander getrennt.

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
bgl
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 43
Registriert: Di, 30. Aug 2011 20:45

Re: PostgreSQL "Index"

Beitrag von bgl »

Noch ein tip: wenn ein Befehl extrem langsam ist, häng mal "EXPLAIN ANALYZE" davor, dann kriegst du statt dem Resultset die Beschreibung, wie es zustande kommt, und wo es hängt.

Wobei deine Statements ja eigentlich relativ simpel sind, also weiss ich nicht, wieviel damit zu gewinnen ist.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Index"

Beitrag von AUGE_OHR »

bgl hat geschrieben:Noch ein tip: wenn ein Befehl extrem langsam ist, häng mal "EXPLAIN ANALYZE" davor, dann kriegst du statt dem Resultset die Beschreibung, wie es zustande kommt, und wo es hängt.
ok das werde ich mal ausprobieren, danke.
bgl hat geschrieben:Wobei deine Statements ja eigentlich relativ simpel sind, also weiss ich nicht, wieviel damit zu gewinnen ist.
es geht im Prinzip um den Xbase++ SEEK() Befehl.

Code: Alles auswählen

__order_fskartei_fskartei
das ist der pgDBE "Index" was als Function nachgebildet wird.
die Function enthält nun wieder die Fields FKDNR+FARTNR welche im 2nd Befehl verwendet wird.

es sind also gleiche Bedingungen und der Index ergibt keinen Vorteil ... das ist meine Frage ???
gruss by OHR
Jimmy
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: PostgreSQL "Index"

Beitrag von georg »

Guten Morgen, Jimmy -


leider komme ich noch einmal mit dem Schlagwort "Paradigmenwechsel".

Bei Xbase++ waren wir es gewöhnt, dass ein gezielter Zugriff nur mit Index möglich war, deshalb gibt es in unserem Gehirn eine Verknüpfung, bei der wir bei einem dbSeek() ähnlichen Zugriff sofort darüber nachdenken, welcher Index zu verwenden ist.

Du hast es jetzt mit SQL zu tun, also vergesse die Indexdateien erst einmal. Ein SQL-Server hat seine eigene Art, Zugriffe zu optimieren. Ich habe gestern abend mit Benjamin einige DELETE Zugriffe ausprobiert, bei denen Abhängigkeiten zwischen drei Dateien abzubilden sind, und ich war erstaunt, wie schnell der Zugriff darstellbar war, wenn alle Felder aus dem PRIMARY KEY der zweiten Datei verwendet wurden.

Normalerweise sollte der Zugriff flott erfolgen. Ist er das nicht, dann solltest Du den ANALYZE Schritt verwenden und Dir vom Server erklären lassen, welcher Index benötigt wird, um den Zugriff zu beschleunigen. Dann kannst Du überlegen, ob dieser Zugriff so oft erfolgt, dass es sich lohnt, den Index zu erstellen.

Hier ist es wie bei Xbase++ - je mehr Index-Dateien an einer Datei hängen, um so mehr Zeit wird im Hintergrund für die Verwaltung der Index-Dateien aufgewendet. Ist der Server auf einem eigentständigen Rechner, kann man das theoretisch vernachlässigen.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Index"

Beitrag von AUGE_OHR »

georg hat geschrieben:leider komme ich noch einmal mit dem Schlagwort "Paradigmenwechsel".
manchmal ist es schwierig, wie bei prozedural nach OOP, das "denken" wie gewöhnt zu betreiben.
erst wenn es "einleuchtet" wie was funktioniert fällt bei mir erst der Groschen.

ich fragte mich ja wofür ich noch einen "Index" brauche. nun hab ich in PGu den Header per o:lbClick zu "sortieren" benutzen wollen.
ein "ORDER BY "+aDbStruc[nColumn] bringt mich zwar auf die Sortierung aber das ist nicht "genug".

es nützt einem oft sehr wenig wenn der INDEXKEY() nur über ein Feld geht ... man hat meistens mehrere Felder.
das wäre ja nun grundsätzlich kein Problem mit "ORDER BY Field1,Field5, ..." aber so was hätte ich ja nicht in meinem aDbStruc Array.

Code: Alles auswählen

pseudo Code

::pgSetIndex(xTab,{Field1,Field3,Field7},{...} )

::pgOrdSetFocus(xTab, nIndex)
und damit könnte man sich "feste Index" Dateien, die nichts "bringen"***, ersparen.
*** pgDBE Style

was meint ihr, geht so was ?
gruss by OHR
Jimmy
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: PostgreSQL "Index"

Beitrag von UliTs »

Warum arbeitest Du nicht einfach mit SQL-Tabellen? Dann stellt sich das Problem nicht!

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: PostgreSQL "Index"

Beitrag von georg »

Hallo, Jimmy -


diese Frage ist vielschichtig.

Reden wir über eine Tabelle, die aller Voraussicht nach nur hundert bis tausend Sätze enthalten wird, kannst Du Dir die entsprechenden Index-Dateien sparen, das bekommt ein SQL-Server auf einem ausreichend ausgestattetem System ohne Probleme hin.

Mein SQL-Server läuft auf einem Ready NAS+ von Netgear, d.h. das ist eine kleine Linux-Box mit ein paar Platten drin, und das Linux dient hauptsächlich der Verwaltung der Daten und der Pflege des RAID-Systems, ist also garantiert nicht auf dem neuesten Prozessor-Stand. Aber der Server ist FLOTT.

Kommen wir jetzt zu Dateien, wo der Kunde die Option erhalten soll, die Ansicht nach jeder beliebigen Spalte zu sortieren. Hat die Datei fünfzehn Felder, die in der Übersicht angezeigt werden, so braucht man theoretisch auch 15 Index-Dateien, wenn man diesen Wunsch schnell (!) bedienen will. Sind wiederum nur um die 1.000 Datensätze drin (plus 1000, minus 900 macht kaum einen Unterschied), sind zusätzlich Index-Dateien nicht zwingend nötig. Ob das auch bei 50.000 oder 500.000 Sätzen gilt, muss ausprobiert werden.

Ansonsten würde ich die wichtigsten Sortierkriterien (drei oder vier, aber diese Zahlen sind MEIN Bauchgefühl) mit einem Index belegen und in der Header-Zeile kennzeichnen, damit man dem Kunden sagen kann "das sind die gängigen Suchkriterien, bei denen geht es schnell. Wenn Sie eine der anderen Spalten verwenden wollen, dann kann das etwas länger dauern, weil ich die Gesamt-Performance auf einem guten Level halten will."

Parallel dazu kannst Du ja eine Statistik führen, welche Sortierung wie oft verwendet wurde und - ganz wichtig! - wie lange es dauerte, die Sortierungen ohne Index bereitzustellen!, und dann aufgrund dieser Daten entscheiden, ob ein Index Sinn macht oder nicht.

Aber genau diese "Spielereien" sind es, die für mich - neben anderen Gründen - den Umstieg auf SQL so attraktiv machen: ein Klick auf den Spaltenkopf, und schon wird die Anzeige "anders herum" sortiert und angezeigt.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: PostgreSQL "Index"

Beitrag von georg »

AUGE_OHR hat geschrieben:hi,

was sollte schneller sein

Code: Alles auswählen

select * from fsicher where "fkdnr" = '11105' ORDER BY __order_fskartei_fskartei
oder

Code: Alles auswählen

select * from fsicher where "fkdnr" = '11105' ORDER BY fkdnr,fartnr
im ersten Fall wäre der "Index" __order_fskartei_fskartei = fkdnr+fartnr, also lägen "hintereinander"

im zweiten Fall erfolgt die "Sortierung" erst bei Auswahl.

Hallo, Jimmy -


Deine Abfrage sieht danach aus, als erwartest Du nur einen Satz im Ergebnis. In diesem Fall würde ich die Abfrage um ein "LIMIT 1" ergänzen, denn der Server wird - abhängig vom gewählten Zugriffsweg nach ALLEN Sätzen suchen, die "passen". Gibt es nur einen, sollte das Limit in etlichen Fällen die Suche verkürzen.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Index"

Beitrag von AUGE_OHR »

georg hat geschrieben:Deine Abfrage sieht danach aus, als erwartest Du nur einen Satz im Ergebnis.
Nope, es sollen wirklich "alle" Artikel von "einen" Kunden im Result auftauchen.

btw. mit LIMIT 1 , und dann in Result:rows -> 1, dauert es wieder bei beiden die gleiche Zeit.

da nun alle Test zeigen das ein "fester Index" keinen "zeitlichen" Vorteil bringt, aber eine Menge Nachteile (Pflege), kann ich dem pgDBE Konzept nicht zustimmen.

ein "Data Dictionary", wie oben skizziert, für die INDEXKEY() wäre IMHO eine bessere Lösung.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Index"

Beitrag von AUGE_OHR »

georg hat geschrieben:Aber genau diese "Spielereien" sind es, die für mich - neben anderen Gründen - den Umstieg auf SQL so attraktiv machen: ein Klick auf den Spaltenkopf, und schon wird die Anzeige "anders herum" sortiert und angezeigt.
hehe ... und genau "da" ergab sich ja das "Problem" mit dem "Index".

wie ich sagte ist

Code: Alles auswählen

oHeader:lbClick := {|aPos,uNil,oSelf| ::SortOrder(aPos,oSelf) } )
kein Problem denn das kann man ja leicht mit "ORDER BY" erreichen.

wenn du das in Xbase++ machst wird sich deine Recno() nicht verändern d.h. ich bleibe auf der Position "stehen"

dass ist aber bei dem "ORDER BY " nicht der Fall sondern ich lande wo anders ... auf dem "ersten" Treffer von "ORDER BY"

Code: Alles auswählen

METHOD JimBrowse:SortOrder(aPos, oSelf)
LOCAL aRowCol  := oSelf:cellFromPos(aPos)
LOCAL i        := 1
LOCAL iMax     := LEN( ::_aBroFields )
LOCAL cOrder   := ""
LOCAL cWhere   := ""

   FOR i := 1 TO iMax
      IF i = aRowCol[2]
         ::oHeader:hiliteCell( 1 , i, .F., .F. )
         cOrder := ::_aBroFields[ i ] [ DBS_NAME ]
//         cWhere := ::oResult:DataBlock( i )
      ELSE
         ::oHeader:hiliteCell( 1 , i, .T., .F. )
      ENDIF
   NEXT
   // relative Position von __record
   ::nRememberRecord := ::DbPosition()

   ::hide()
   ::ReadNextData(,,, cOrder,,)
   ::Show()
ich muss mir also erst die "relative" Position von "__record" merken.
wenn ich dann den "neue Lastrec" ermittelt habe kann ich ihn so "re-positionieren"

Code: Alles auswählen

CASE nEvent == xbeE_IndexReady

IF oSQLdialog:oBrowse:nRememberRecord > 0
   nOffset := oSQLdialog:oBrowse:DbPosition(oSQLdialog:oBrowse:nRememberRecord
   oSQLdialog:oBrowse:nRememberRecord := 0

   IF nOffset > 0
      cOffSet := LTRIM(STR( nOffset-1 ))
      oSQLdialog:oBrowse:hide()
      oSQLdialog:oBrowse:ReadNextData(,,,,,cOffSet)
      oSQLdialog:oBrowse:Show()
   ENDIF
ENDIF
und stehe jetzt erst wieder auf "dem __record" wo ich vorher war.

gibt es dafür eine "bessere" ( und schnellere ) Lösung ?
gruss by OHR
Jimmy
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: PostgreSQL "Index"

Beitrag von georg »

Hallo, Jimmy -


bei Xbase bleibst Du im gleichen "result set", wenn Du einen ordSetFocus() durchführst, bei SQL erzeugst Du ein neues "result set", mit dem Ergebnis, dass die alte Position nicht mehr relevant ist.

Auf Anhieb fällt mir keine wasserdichte Lösung ein. Du kannst zwar den Spaltenwert speichern und mit ein, zwei SELECT COUNT(*) ... WHERE ... Anweisungen die etwaige Position finden, um dann mit SELECT ... LIMIT ... OFFSET ... auf diesen Satz zu positionieren. Wenn aber der Wert in der Spalte mehrfach vorkommt, wird das ganze zu einem va banque Spiel, weil Du wahrscheinlich den ersten Satz mit diesem Wert treffen wirst.

Aber auch hier stellt sich dann die Frage: will der Anwender auf genau diesem Satz weiterarbeiten, oder in der Gruppe der Werte? Dann wäre ein 100% Treffergenauigkeit zu vernachlässigen.

Aber: es ist schwer, einem Kunden zu erklären, dass ein moderneres DBMS weniger kann.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Index"

Beitrag von AUGE_OHR »

hi
georg hat geschrieben:bei Xbase bleibst Du im gleichen "result set", wenn Du einen ordSetFocus() durchführst, bei SQL erzeugst Du ein neues "result set", mit dem Ergebnis, dass die alte Position nicht mehr relevant ist.
YUP ... deshalb komme ich darauf das ein "re-positionieren" von uns "manuell" durchgeführt werden müsste.
ich will also immer auf dem Datensatz stehen wo die "__record" == 1234 ist ... wenn im Result Set vorhanden ist.

da ich mich auch noch um den vertikale Scrollbar "kümmern" muss brauche ich eh ein Array.
meine METHOD ::DbPosition() funktioniert soweit nur da ich mit Threads arbeite muss ich das o:lbclick noch auf die Threads synchronisieren weil sonst so was passiert.
Send Query :
SELECT table_name FROM information_schema.tables WHERE table_schema = 'public'
9 Tables:
customer
parts
artikel
fsicher
umsatz
abzu

select Table : umsatz AS a
Send Query :
SELECT * FROM umsatz AS a LIMIT 1
Answer Result :

urechnr C 9
ukdname C 25
umsatzges N 9
urechdat C 8
ok C 1
tz N 1
ma N 1
ukdnr C 5
uplz C 5
uort C 25
uvierzehn N 9
umvierzehn N 8
usieben N 9
umsieben N 8
umgesamt N 9
uskonto N 6
usgesamt N 8
ubezahlt N 10
ugutschrif N 10
ustand N 10
ubezadat D 10
isdatev C 1

27 Fields :

used Fields for Column :

a.urechnr
a.ukdname
a.umsatzges
a.urechdat
a.ok
a.tz
a.ma
a.ukdnr
a.uplz
a.uort
a.uvierzehn
a.umvierzehn
a.usieben
a.umsieben
a.umgesamt
a.uskonto
a.usgesamt
a.ubezahlt
a.ugutschrif
a.ustand
a.ubezadat
a.isdatev
a.__deleted
a.__record
a.__rowversion
a.__keyversion
a.__lock_owner

now browse

SELECT a.urechnr,a.ukdname,a.umsatzges,a.urechdat,a.ok,a.tz,a.ma,a.ukdnr,a.uplz,a.uort,a.uvierzehn,a.umvierzehn,a.usieben,a.umsieben,a.umgesamt,a.uskonto,a.usgesamt,a.ubezahlt,a.ugutschrif,a.ustand,a.ubezadat,a.isdatev,a.__deleted,a.__record,a.__rowversion,a.__keyversion,a.__lock_owner FROM umsatz AS a
Start request :07:49:34
finsh request after 0.02 Sec.
create Browse :07:49:34
read Data ...
Browse Pop-Up after 0.08 Sec.
SELECT a.urechnr,a.ukdname,a.umsatzges,a.urechdat,a.ok,a.tz,a.ma,a.ukdnr,a.uplz,a.uort,a.uvierzehn,a.umvierzehn,a.usieben,a.umsieben,a.umgesamt,a.uskonto,a.usgesamt,a.ubezahlt,a.ugutschrif,a.ustand,a.ubezadat,a.isdatev,a.__deleted,a.__record,a.__rowversion,a.__keyversion,a.__lock_owner FROM umsatz AS a ORDER BY __record LIMIT 25 OFFSET 0

find Last Record in SERIAL Field __record
Query : SELECT * FROM umsatz___record_seq
Table have 9 Property 0.01 Sec.

sequence_name : umsatz___record_seq
last_value : 44718
increment_by : 1
max_value : 9223372036854775807
min_value : 1
cache_value : 1
log_cnt : 31
is_cycled : f
is_called : t

Table have 44718 entry 0.00 Sec.
Index : SELECT __record FROM umsatz AS a ORDER BY __record

create Index 44718 Records 2.48 Sec.

nIsRec 13 field 00-01010 nOutRec 13
sort ORDER BY urechnr WHERE 00-01010 Recno 13

find Last Record in SERIAL Field __record
Query : SELECT * FROM umsatz___record_seq
SELECT a.urechnr,a.ukdname,a.umsatzges,a.urechdat,a.ok,a.tz,a.ma,a.ukdnr,a.uplz,a.uort,a.uvierzehn,a.umvierzehn,a.usieben,a.umsieben,a.umgesamt,a.uskonto,a.usgesamt,a.ubezahlt,a.ugutschrif,a.ustand,a.ubezadat,a.isdatev,a.__deleted,a.__record,a.__rowversion,a.__keyversion,a.__lock_owner FROM umsatz AS a ORDER BY urechnr LIMIT 25 OFFSET 0
Table have 9 Property 0.00 Sec.

sequence_name : umsatz___record_seq
last_value : 44718
increment_by : 1
max_value : 9223372036854775807
min_value : 1
cache_value : 1
log_cnt : 31
is_cycled : f
is_called : t

Table have 44718 entry 0.00 Sec.
Index : SELECT __record FROM umsatz AS a ORDER BY urechnr

create Index 44718 Records 2.50 Sec.

nInRec 13 nPosRec 3335 nOutRec 13
nIsRec 13 field 00-01010 nOutRec 13
sort ORDER BY ukdname WHERE Harms Food Trading Recno 13

find Last Record in SERIAL Field __record
Query : SELECT * FROM umsatz___record_seq
SELECT a.urechnr,a.ukdname,a.umsatzges,a.urechdat,a.ok,a.tz,a.ma,a.ukdnr,a.uplz,a.uort,a.uvierzehn,a.umvierzehn,a.usieben,a.umsieben,a.umgesamt,a.uskonto,a.usgesamt,a.ubezahlt,a.ugutschrif,a.ustand,a.ubezadat,a.isdatev,a.__deleted,a.__record,a.__rowversion,a.__keyversion,a.__lock_owner FROM umsatz AS a ORDER BY ukdname LIMIT 25 OFFSET 12
Table have 9 Property 0.00 Sec.

sequence_name : umsatz___record_seq
last_value : 44718
increment_by : 1
max_value : 9223372036854775807
min_value : 1
cache_value : 1
log_cnt : 31
is_cycled : f
is_called : t

Table have 44718 entry 0.00 Sec.
Index : SELECT __record FROM umsatz AS a ORDER BY ukdname

create Index 44718 Records 3.64 Sec.

nInRec 13 nPosRec 3335 nOutRec 17514
nIsRec 13 field 00-01010 nOutRec 13
sort ORDER BY umsatzges WHERE 1991.38 Recno 13

find Last Record in SERIAL Field __record
Query : SELECT * FROM umsatz___record_seq
Table have 9 Property 0.00 Sec.

sequence_name : umsatz___record_seq
last_value : 44718
increment_by : 1
max_value : 9223372036854775807
min_value : 1
SELECT a.urechnr,a.ukdname,a.umsatzges,a.urechdat,a.ok,a.tz,a.ma,a.ukdnr,a.uplz,a.uort,a.uvierzehn,a.umvierzehn,a.usieben,a.umsieben,a.umgesamt,a.uskonto,a.usgesamt,a.ubezahlt,a.ugutschrif,a.ustand,a.ubezadat,a.isdatev,a.__deleted,a.__record,a.__rowversion,a.__keyversion,a.__lock_owner FROM umsatz AS a ORDER BY umsatzges LIMIT 25 OFFSET 17513
cache_value : 1
log_cnt : 31
is_cycled : f
is_called : t

Table have 44718 entry 0.00 Sec.
Index : SELECT __record FROM umsatz AS a ORDER BY umsatzges

create Index 44718 Records 2.67 Sec.

nInRec 13 nPosRec 3335 nOutRec 40023
und bei nOutRec stimmt hier was nicht ...

während er im Thread mit der "Sequence" noch beschäftigt ist geht evtl. schon der nächste los. (siehe SELECT ... OFFSET und was danach kommt )
ich hab wohl schon was "frei" gegeben habe während der Tread noch läuft was in der vorletzten Zeile passiert.

Code: Alles auswählen

   ::lisValidIndex := .T.
RETURN ::aIndex 
damit hat der Thread "freie Bahn" bevor ich das RETURN erreiche und den nächsten Schritt ausführen kann.

:banghead:
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Index"

Beitrag von AUGE_OHR »

hi,

vorsichtshalber wieder eine Newbie Frage : ist __order_custa_custa ein "Index" ?

es wird ja die "function" custa_custa_seek von DbfUpsize.EXE angelegt und im MDIDEMO als "Index" verwendet.

nun "sehe" ich in pgAdmin.EXE das
CustA_CustA.PNG
CustA_CustA.PNG (3.11 KiB) 14780 mal betrachtet
was hab ich "übersehen" ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Index"

Beitrag von AUGE_OHR »

hi,

ich versuche die Frage mal "allgemeiner" zu formulieren :
ist die Verwendung einer PostgreSQL "function", welche die entsprechenden Fields enthält, mit "ORDER BY __Order_Name_Name" das "selbe" wie ein "Index" wobei mich nur die Geschwindigkeit interessiert.
gruss by OHR
Jimmy
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: PostgreSQL "Index"

Beitrag von UliTs »

:?:
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Index"

Beitrag von AUGE_OHR »

hi,

so langsam komme ich der Sache näher ...

a.) eine PostgreSQL "function" kann ein "Funktionsindexe" (Kapitel 11.5) sein
b.) ein "PRIMARY KEY" kann ein "Index" sein

unterschied zu einem "echten Index" : ein "Index" wird "automatisch" mit einer Table geladen.

wann ist ein "Index" denn "aktive" ?
auf die Frage hat mit Georg erst gebracht also hab ich mit EXPLAIN im pgAdmin.EXE paar Eingaben ausprobiert.

Antwort : wenn er "gebraucht" wird ... ;)

und "wann" wird was "gebraucht" ? ...

Antwort : bei einer Abfrage mit WHERE
WHERE_FsKartei.PNG
WHERE_FsKartei.PNG (23.38 KiB) 14790 mal betrachtet
das ist vermutlich die Lösung warum es beim "navigieren" es keinen Geschwindigkeitsunterschied gibt ...
ich habe bei einer "ganzen" Table ja keine "Beschränkung" mittels WHERE


zurück zur
a.) "functionindex" das ist das was DbfUpSize.EXE und pgDBE verwenden.
eine "function" muss mit "ORDER BY functionname" aktiviert werden

b.) der "PRIMARY KEY" wird, wenn vorhanden, immer dann ( automatisch ) benutzt wenn man kein "ORDER BY" verwendet, oder ?

Code: Alles auswählen

     EXPLAIN SELECT * FROM Fsicher -> _pkey -> __record
ich habe also bislang gar keine "echten Indexe" verwendet und erst beim WHERE wird sich zeigen ob es einen Unterschied gibt.

ohne "Index"
a.) EXPLAIN select * from fsicher where fkdnr = '11105' order by __order_Name_Name
b.) EXPLAIN select * from fsicher where fkdnr = '11105' order by fkdnr,fartnr

bei beiden wird mir ein "Filter" angezeigt. beide sind gleich schnell ca. 1 Sec.

mit "Index"
EXPLAIN select * from fsicher where fkdnr = '11105'

nun zeigt er mit den "Index" FsKartei an und er benötigt 250ms ... so funktioniert das also =D>
gruss by OHR
Jimmy
bgl
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 43
Registriert: Di, 30. Aug 2011 20:45

Re: PostgreSQL "Index"

Beitrag von bgl »

Zunaechst: fuer realistische Ergebnisse in PostgreSQL empfehle ich nicht EXPLAIN, sondern EXPLAIN ANALYZE (wenigstens bei SELECT abfragen), da hier nicht nur geschaetzt wird, sondern der Befehl tatsaechlich ausgefuehrt wird, um das Ergebnis zu pruefen.

Dann: ein unsortierter SELECT *benutzt* den PRIMARY KEY fuer das ein- oder andere, er wird aber nicht nach dem PRIMARY KEY sortiert.

Und für den PRIMARY KEY wird immer ein entsprechender Index ganz automatisch angelegt.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Index"

Beitrag von AUGE_OHR »

bgl hat geschrieben:Zunaechst: fuer realistische Ergebnisse in PostgreSQL empfehle ich nicht EXPLAIN, sondern EXPLAIN ANALYZE (wenigstens bei SELECT abfragen), da hier nicht nur geschaetzt wird, sondern der Befehl tatsaechlich ausgefuehrt wird, um das Ergebnis zu pruefen.
ok das werde ich überprüfen.
am "grundsätzlichen" Resultat, das ein "functionIndex" kein "real Index" ist sondern nur ein "Filter" ist, ändert es wohl nichts.

meine "allgemeine" Frage lautet deshalb : man könnte doch leicht aus dem "functionIndex" einen "echte" PostgreSQL "Index" machen ?

nicht nur weil er 300% schneller ist sondern weil wir uns dann "wirklich" nicht um den ganzen "Rest" kümmern müssen.
bgl hat geschrieben:Dann: ein unsortierter SELECT *benutzt* den PRIMARY KEY fuer das ein- oder andere, er wird aber nicht nach dem PRIMARY KEY sortiert.
Und für den PRIMARY KEY wird immer ein entsprechender Index ganz automatisch angelegt.
ok das war wieder von mir falsch ausgedrückt.
unter Xbase++ ist bei mir der 1st Index / Tag einer "Stamm" Datei "ähnlich" einem "PRIMARY KEY"

so wie ich DBF und Index in einer Function "öffne" hab ich es auch für PostgreSQL Table ausgelegt.
default wird also immer "das" Field in die "ORDER BY " Bedingung vorgegeben im Source ... in pgAdmin.EXE "vergesse" ich das oft ...

am liebsten würde ich die FUNCTION in eine PostgreSQL "function" packen ...

Code: Alles auswählen

SELECT DataDic_Net_Use("meineTable")
geht so was ?
gruss by OHR
Jimmy
bgl
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 43
Registriert: Di, 30. Aug 2011 20:45

Re: PostgreSQL "Index"

Beitrag von bgl »

AUGE_OHR hat geschrieben:am liebsten würde ich die FUNCTION in eine PostgreSQL "function" packen ...

Code: Alles auswählen

SELECT DataDic_Net_Use("meineTable")
geht so was ?
So ganz kapiere ich gerade nicht, *was* du in die STORED FUNCTION stopfen willst, fuerchte aber, dass wenn du da einen Wrapper fuer die Standard-Variante deines SELECT bauen willst, du an ein paar boese Stolpersteine stossen wirst - und selbst wenn nicht muss ich dich leider warnen: schneller wirds dadurch nicht.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Index"

Beitrag von AUGE_OHR »

bgl hat geschrieben:So ganz kapiere ich gerade nicht, *was* du in die STORED FUNCTION stopfen willst, fuerchte aber, dass wenn du da einen Wrapper fuer die Standard-Variante deines SELECT bauen willst, du an ein paar boese Stolpersteine stossen wirst - und selbst wenn nicht muss ich dich leider warnen: schneller wirds dadurch nicht.
in Xbase++ kann ich FUNCTION für Xbase++ Code verwenden aber nicht innerhalb eines SQL Query.
wenn ich nun in einem Catalog eine "function" anlege kann ich die in einer SQL Query zu einer Table daraus verwenden.

Frage : ich kann doch dann auch in pgAdmin.EXE die "function" verwenden ?

eine "function" DataDic_Net_Use("meineTable") wäre also das Gegenstück zu meinem Xbase++ Data-Dic wo ich DBF / Index "öffne" und alles was "dazu" gehört.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL "Index"

Beitrag von AUGE_OHR »

hi,

das ein "Index" nur unter bestimmten "Bedingungen" in Erscheinung trifft und nicht "automatisch" ein "ORDER BY" beinhaltet ist mir soweit klar.
nun hab ich bisher nur "WHERE" gefunden wo "EXPLAIN" mir sagt das ein "Index" aktive sei.

Frage : "wobei" wird ein "Index" noch aktiviert ?

nun kann ich wohl auch mehrere "Index"e anlegen.
um ein OrdSetFocus() muss ich mich nicht "kümmern" , PostgreSQL nimmt den "passenden" ;)

Frage : was passiert wenn ich mehrere "ähnliche Index" habe ?

Code: Alles auswählen

   _key := "FKDNR+FARTNR"
   _key := "FKDNR+FFJAHR+FFMONAT+FFTAG"
   _key := "FKDNR+IF(EMPTY(FNUMMER),'J','N')+FFJAHR+FFMONAT+FFTAG"
wären INDEXKEY() Ausdrücke ... -> "Index"

Code: Alles auswählen

SELECT * FROM MyTable WHERE FKDNR='11105'
würde je nach "Index" unterschiedliche Ergebnisse produzieren wenn ich ihm nicht sagen kann "welchen" er verwenden soll ... oder ?
gruss by OHR
Jimmy
UliTs
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2828
Registriert: Fr, 10. Feb 2006 9:51
Wohnort: Aachen
Hat sich bedankt: 259 Mal
Danksagung erhalten: 12 Mal
Kontaktdaten:

Re: PostgreSQL "Index"

Beitrag von UliTs »

AUGE_OHR hat geschrieben:Frage : was passiert wenn ich mehrere "ähnliche Index" habe ?

Code: Alles auswählen

   _key := "FKDNR+FARTNR"
   _key := "FKDNR+FFJAHR+FFMONAT+FFTAG"
   _key := "FKDNR+IF(EMPTY(FNUMMER),'J','N')+FFJAHR+FFMONAT+FFTAG"
wären INDEXKEY() Ausdrücke ... -> "Index"

Code: Alles auswählen

SELECT * FROM MyTable WHERE FKDNR='11105'
würde je nach "Index" unterschiedliche Ergebnisse produzieren wenn ich ihm nicht sagen kann "welchen" er verwenden soll ... oder ?
Jimmy,
Du hast Dich inzwischen intensiv mit SQL beschäftigt :-) .
Also weißt Du inzwischen sicher, dass ein Ergebnis eines SELECT-Statements ohne Order-by oder Group by-Klausel keine definierte Reihenfolge hat!
Explizit angelegte Indizes werden ausschließlich zur internen Optimierung der SQL-Implementation verwendet.
Folglich sind Deine beiden gestellten Fragen unsinnig :? .
Ich würde übrigens keine Ausdrücke mehr in Indexdefinitionen verwenden! Nach meiner Erfahrung kann der SQL-Server selbige viel schlechter zur Optimierung einsetzen.

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: PostgreSQL "Index"

Beitrag von georg »

Guten Morgen, Jimmy -


vielleicht liegt's an zu wenig Schlaf, aber ...
_key := "FKDNR+IF(EMPTY(FNUMMER),'J','N')+FFJAHR+FFMONAT+FFTAG"
Was ist den dass für ein Index? Sollte eigentlich so aussehen:

Code: Alles auswählen

FKDNR, FNUMMER, FFJAHR, FFMONAT, FFTAG
da bei SQL der Index-Ausdruck aus unterschiedlichen Feldtypen zusammengesetzt sein kann.

Insbesondere ein Verketten der Felder kann zu Schwierigkeiten führen, wenn die Zeichenfeld "trimmed" abgelegt werden.


Gruss,

Georg
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Antworten