Martin Altmann hat geschrieben:ORDER BY hat nichts damit zu tun, ob es in der Datenbank auch einen passenden Index gibt!
ich "dachte" ich hätte mittels pgAdmin.EXE "bewiesen" das es
KEINEN UNTERSCHIED macht ob du einen "Index" nimmst oder die selben Fields "on-fly" im "SELECT ... ORDER BY " verwendest.
Martin Altmann hat geschrieben:Gibt es einen, wird der bei der Anweisung auch genommen und es geht schneller. ...
ich höre euch das immer wieder sagen, aber ich finde kein Beispiel wo ich das Gegenteil erkennen könnte.
vielleicht muss ich das System anders "stressen" damit ich den Effekt erkenne, aber beim "blättern" und "positionieren" erziele ich keine Zeit Unterschiede wie es "theoretisch" ja sein sollte.
ich habe nun im PostgeSQL Handbuch durchaus Sachen gesehen, so "verschachtelt", das es vielleicht in solchen Fällen einen Vorteil bringen könnte, aber so was kann "ich" nicht zusammenbauen und pg
DBE ...
pg
DBE soll doch "was einfaches" werden und der Xbase++ soll "vorhandenes" verwenden können.
wir sind gewohnt mit DBSEEK(), SKIP() und GOTO() zu arbeiten was ja nun "Satz-orientiert" ist.
wenn ich aber pg
DBE versucht an dem "alten" Konzept von Phil Ide festzuhalten statt sich was "einfallen" zu lassen wie man das ganze "optimieren" könnte dann habe ich Zweifel am "Index" Konzept mit pg
DBE ... wenn es keine Vorteil bringt ?!
Ein Data-Dic mit INDEXKEY(), was man zur Laufzeit "verändern" kann, wäre eine viel "wartungsfreundlichere" Lösung und IMHO "genau so schnell"
***
nein es ist wieder das alte Spiel das er beim "MOVE" eben doch immer von "vorne" losgeht
wenn ich __record verwende wären die Daten wirklich "hintereinander".
bei einer "ORDER BY " auf "PRIMARY KEY" Field, die ja auch "hintereinander" liegen "sollten" ist es ähnlich schnell.
wie schnell ... hier paar Zahlen :
finsh request after 0.01 Sec.
Browse Pop-Up after 0.03 Sec.
SELECT
a.fkdnr,a.fmonat,a.fnummer,a.fartnr,a.fartikel,a.fanzahl,a.feinh,a.bpreis,a.fstu
eck,a.fmwst,a.mschl,a.fpreis,a.skonto,a.fjahr,a.fftag,a.ffmonat,a.ffjahr,a.ftext
,a.dflag,a.liefnr,a.lflag,a.rechwahl,a.aqnr,a.__deleted,a.__record,a.__rowversio
n,a.__keyversion,a.__lock_owner FROM fsicher AS a ORDER BY __record LIMIT 25
MOVE 0
BEGIN WORK : 0.00 Sec.
DECLARE MyCursor: 0.00 Sec.
FETCH FORWARD : ORDER BY __record after 0.00 Sec.
Get Result : 0.03 Sec.
CLOSE MyCursor : 0.00 Sec.
COMMIT WORK : 0.00 Sec.
Index : SELECT __record FROM fsicher AS a ORDER BY __record
BEGIN WORK : 0.00 Sec.
DECLARE MyCursor: 0.00 Sec.
MOVE FORWARD : 0.00 Sec.
FETCH FORWARD : ORDER BY __record after 0.00 Sec.
Get Result : 0.04 Sec.
CLOSE MyCursor : 0.00 Sec.
COMMIT WORK : 0.00 Sec.
BEGIN WORK : 0.00 Sec.
DECLARE MyCursor: 0.00 Sec.
MOVE FORWARD : 0.00 Sec.
FETCH FORWARD : ORDER BY __record after 0.00 Sec.
Get Result : 0.05 Sec.
CLOSE MyCursor : 0.00 Sec.
COMMIT WORK : 0.00 Sec.
BEGIN WORK : 0.03 Sec.
DECLARE MyCursor: 0.00 Sec.
MOVE FORWARD : 0.00 Sec.
FETCH FORWARD : ORDER BY __record after 0.00 Sec.
Get Result : 0.03 Sec.
CLOSE MyCursor : 0.00 Sec.
COMMIT WORK : 0.00 Sec.
BEGIN WORK : 0.00 Sec.
DECLARE MyCursor: 0.00 Sec.
MOVE FORWARD : 0.00 Sec.
FETCH FORWARD : ORDER BY __record after 0.00 Sec.
Get Result : 0.03 Sec.
CLOSE MyCursor : 0.00 Sec.
COMMIT WORK : 0.00 Sec.
normales "blättern" im Browse dauert 0.03-0.04Sec und ein DbGoBottom() 0.05sec ... und das auf dem P4 3GHz und > 550000 Record
aber wie schon gesagt die Sache sieht ganz anders aus wenn ich
denn das muss ja nicht mehr die "natürliche" Reihenfolge sein.
hier ist nun wieder "Power" angesagt den auch das "
MOVE" reagiert da leider nur mit "Power"
create Index 572596 Records 44.22 Sec.
nIsRec 101 field 23678 nOutRec 101
change to ORDER BY fartikel WHERE Recno 101
SELECT
a.fkdnr,a.fmonat,a.fnummer,a.fartnr,a.fartikel,a.fanzahl,a.feinh,a.bpreis,a.fstu
eck,a.fmwst,a.mschl,a.fpreis,a.skonto,a.fjahr,a.fftag,a.ffmonat,a.ffjahr,a.ftext
,a.dflag,a.liefnr,a.lflag,a.rechwahl,a.aqnr,a.__deleted,a.__record,a.__rowversio
n,a.__keyversion,a.__lock_owner FROM fsicher AS a ORDER BY fartikel LIMIT 25
MOVE 100
BEGIN WORK : 0.00 Sec.
DECLARE MyCursor: 0.07 Sec.
MOVE FORWARD : 38.26 Sec.
FETCH FORWARD : ORDER BY fartikel after 0.00 Sec.
Get Result : 0.03 Sec.
CLOSE MyCursor : 0.78 Sec.
COMMIT WORK : 0.00 Sec.