PostgreSQL "Index"

Alles zum PostgreSQL-Server

Moderator: Moderatoren

Re: PostgreSQL "Index"

Beitragvon brandelh » Do, 09. Aug 2012 8:41

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 ;-)
Gruß
Hubert
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
 
Beiträge: 13498
Registriert: Mo, 23. Jan 2006 21:54
Wohnort: Germersheim

Re: PostgreSQL "Index"

Beitragvon AUGE_OHR » Do, 09. Aug 2012 9:25

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 ...
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10315
Registriert: Do, 16. Mär 2006 8:55
Wohnort: Hamburg

Re: PostgreSQL "Index"

Beitragvon georg » Do, 09. Aug 2012 10:59

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
Liebe Grüsse aus der Eifel,

Georg
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
 
Beiträge: 1848
Registriert: Fr, 08. Feb 2008 22:29

Re: PostgreSQL "Index"

Beitragvon AUGE_OHR » Sa, 11. Aug 2012 5:55

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 ...
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
 
Beiträge: 10315
Registriert: Do, 16. Mär 2006 8:55
Wohnort: Hamburg

Vorherige

Zurück zu SQL-Server

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast