Inoffizielles deutsches Xbase-Forum

Das sind nicht die Server Indexe, sondern die die bisher für die Sortierung zuständig waren.
Wenn man von der pgDBE erwartet, dass sie sich ohne Änderung verhält wie zuvor, denke ich müsste man hier mit Xbase++ commandos den Index (intern dann das Indexfeld) aussuchen:

Code: Alles auswählen

use ... // hier eventuell dann ein SELECT ? wie war es bei der ODBCDBE ?
set index to ...
set order to ...

dafür ist die pgDBE gemacht und so müsste sie sich dann verhalten

UliTs hat geschrieben: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!

vielleicht ist das bei ADS so aber pgAdmin.EXE "sagt" mit bei

Code: Alles auswählen

EXPLAIN SELECT * FROM MyTable WHERE FKDNR='11105'

das ich mit meinem "real Index" arbeite wobei ich "ORDER BY __record" (default) gesetzt habe. es ist also IMMER ein "ORDER BY" gesetzt !
p.s. das Field FKDNR ist selbstverständlich im "real Index"

UliTs hat geschrieben:Explizit angelegte Indizes werden ausschließlich zur internen Optimierung der SQL-Implementation verwendet.
Folglich sind Deine beiden gestellten Fragen unsinnig .

Nope den
a.) gibt er mit ja einen "richtigen" Treffer (ich rede nicht davon was "dahinter" kommt ...)
b.) ist die Frage "welchen" der 3 "real Indexe" er denn verwendet wenn ich "ORDER BY __record" (default) angebe !

tatsächlich scheine ich mit "BY ORDER " aber eine "Einfluss" darauf nehmen zu können "welcher" nun als "optimal" angesehen wird.

Code: Alles auswählen

   _key := "FKDNR+FARTNR"
   _key := "FKDNR+FFJAHR+FFMONAT+FFTAG"
   _key := "FKDNR+IF(EMPTY(FNUMMER),'J','N')+FFJAHR+FFMONAT+FFTAG"

wenn man diese INDEYKEY() nun als "real Index" ("MyIndex1","MyIndex2","MyIndex3" ) anlegen würde und dann folgendes macht.

Code: Alles auswählen

"SELECT ... ORDER BY __record"

"SELECT ... ORDER BY FKDNR,FARTNR"

"SELECT ... ORDER BY FKDNR,FFJAHR,FFMONAT,FFTAG"

dann wird man im 1st und 2nd Beispiel "MyIndex1" verwendet und im 3rd. Beispiel "MyIndex2" was man als "real Index" dann in pgAdmin.EXE "sehen" kann welcher bei "EXPLAIN" benutzt wird.

UliTs hat geschrieben:Ich würde übrigens keine Ausdrücke mehr in Indexdefinitionen verwenden! Nach meiner Erfahrung kann der SQL-Server selbige viel schlechter zur Optimierung einsetzen.

die INDEXKEY() Ausdrücke sind nur für das Xbase++ Verständnis, oder ´meinst du EMPTY() was es ja in PostgreSQL "so" nicht gibt.

georg hat geschrieben:Was ist den dass für ein Index? Sollte eigentlich so aussehen:
Code:
FKDNR, FNUMMER, FFJAHR, FFMONAT, FFTAG

YUP, das ist noch der INDEXKEY() gewesen.
"MyIndex1" wird selbstverständlich mit der "richtigen" Syntax erzeugt.
"MyIndex3" existiert noch nicht weil ich noch nicht das "richtige" für EMPTY() gefunden habe.

hubert hat geschrieben: Das sind nicht die Server Indexe, sondern die die bisher für die Sortierung zuständig waren.
Wenn man von der pgDBE erwartet, dass sie sich ohne Änderung verhält wie zuvor, denke ich müsste man hier mit Xbase++ commandos den Index (intern dann das Indexfeld) aussuchen:
Code: Alles auswählen
use ... // hier eventuell dann ein SELECT ? wie war es bei der ODBCDBE ?
set index to ...
set order to ...
dafür ist die pgDBE gemacht und so müsste sie sich dann verhalten

hm ... "das" müsste man mal ausprobieren ...

Hallo, Jimmy -

Du vermischst immer wieder Xbase++ und SQL. Ein SET ORDER TO Index1 wirkt innerhalb von Xbase++, während ein EXPLAIN innerhalb des SQL-Servers wirkt.

Wenn Du ein SET ORDER TO Index1 setzt, und dann den

Code: Alles auswählen

SELECT * FROM table WHERE field = x

dann hast Du keine ORDER Komponente. Jetzt greift der Optimizer des Servers, und der stellt fest, dass ein anderer Index (Index2) nach field aufgebaut ist. Zur Lokalisierung des Satzes/der Sätze greift der Server jetzt über Index2 zu.

Sollte dbPGE jetzt noch ein ORDER BY angehangen haben, um dem SET ORDER TO Index1 Genüge zu tun, dann kann der Server das Ergebnis nochmals nach ORDER BY (Schlüsselfelder von Index1) sortieren!

Wie Uli schon schrieb, einem SQL-Server ist ein ORDER BY schnurzpiepsegal. Ein Server sieht nur die ad hoc-Abfrage und reagiert darauf.

Gruss,

Georg

hi,

mir ist schon klar das bei SQL die Ausführung "auf dem Server" passiert und das der "Optimierung" dann "entscheidet" welcher "real Index" verwendet wird.
mit EXPLAIN kann ich dann, in pgAdmin.EXE, sehen welchen "real Index" er "vorschlägt".

nun kommt meine "Test Bedingungen"

"real Index"
a.) auf Field A,B
c.) auf Field A,C
b.) auf Field A,D,E,F

Abfragen in pgAdmin.EXE
"PRIMARY KEY" __record

Code: Alles auswählen

EXPLAIN SELECT * FROM MyTable WHERE A="11105" ORDER BY __recored

-> "real Index" a.)

Code: Alles auswählen

EXPLAIN SELECT * FROM MyTable WHERE A="11105" ORDER A

->"real Index" a.)

Code: Alles auswählen

EXPLAIN SELECT * FROM MyTable WHERE A="11105" ORDER A,B

-> "real Index" a.)

Code: Alles auswählen

EXPLAIN SELECT * FROM MyTable WHERE A="11105" ORDER A,C

-> "real Index" b.) !!!

Code: Alles auswählen

EXPLAIN SELECT * FROM MyTable WHERE A="11105" ORDER A,D

-> "real Index" c.) !!!

ich kann also, zumindest laut pgAdmin.EXE, per "ORDER BY" einen "Einfluss" darauf nehmen "welchen" der "real Index" er "vorschlägt".

für die SQL "Denker" : es geht "nur" um den ersten "Treffer" der je nach "real Index" eine andere __record ( RECNO() ) hat.
was ich dann weiter mit "Sortierung" oder anderem vorhabe ist noch eine andere Geschichte ...

Inoffizielles deutsches Xbase-Forum

PostgreSQL "Index"

Re: PostgreSQL "Index"

Re: PostgreSQL "Index"

Re: PostgreSQL "Index"

Re: PostgreSQL "Index"