Index Ascending unter PostgreSQL

Bei der Migration einer DB2 Datenbank nach PostgreSQL bin ich auf das Problem gestossen die aufsteigend sortierten Indexspalten entsprechend in einem PostgreSQL-Index umzusetzen. Das Ergebnis von Gevatter Google und Handbuch ist nicht ganz nachvollziehbar. Habe ich das richtig verstanden, dass hierfür Operatorklassen verwendet werden? Wenn ja wie sieht die dann aus, muss die extra erstellt werden?

Zum besseren Verständnis…

DB2:

CREATE TABLE ALM_MESSAGE_DATA  (
	ALM_MSG_SENDER VARCHAR(64) NOT NULL, 
	ALM_MSG_SNDRID INTEGER NOT NULL,
	ALM_MSG_BODY VARCHAR(2048) NOT NULL, 
	ALM_MSG_CRTDATE TIMESTAMP NOT NULL WITH DEFAULT CURRENT TIMESTAMP ) IN ALMDBTS01; 

CREATE INDEX I_ALM_SENDER_CREAT ON ALM_MESSAGE_DATA 
		(ALM_MSG_SENDER ASC,
		 ALM_MSG_CRTDATE ASC);

PostgreSQL:

CREATE TABLE ALM_MESSAGE_DATA  (
	ALM_MSG_SENDER VARCHAR(64) NOT NULL, 
	ALM_MSG_SNDRID INTEGER NOT NULL,
	ALM_MSG_BODY VARCHAR(2048) NOT NULL, 
	ALM_MSG_CRTDATE TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ) TABLESPACE "ALMDBTS01";

CREATE INDEX I_ALM_SENDER_CREAT ON ALM_MESSAGE_DATA 
		(ALM_MSG_SENDER,
		 ALM_MSG_CRTDATE);

Wie gefragt … wie sortiere ich die Index-Spalten nun?
Danke im voraus für Eure Unterstützung.

hi,

ich hab hier jetzt mal etwas rumgeschaut aber nicht wirklich was gefunden. mal dumm gefragt, wieso sortierst du den index? das macht er doch automatisch…

bei postgresql wird hier der b-tree (http://de.wikipedia.org/wiki/B-tree) für indexes standardmäßig verwendet. der macht das ja automatisch…

cu tb.

Vielen Dank für die Info.
Na wenn das so ist. Ich habe mir so etwas fast gedacht, aber nichts gefunden was das eindeutig bestätigte. Die Idee nach B-tree zu googeln war clever. Da hätte man auch drauf kommen können.

Ist jetzt für diesen speziellen Fall nicht so wichtig, aber es interessiert mich halt: Wie würde man eine absteigende Sortierung erreichen? Naja, ich google mal nach R-tree, gist und hash. Vielleicht macht mich das schlauer.

Nochmals danke.

hi,

eine sortierung in diesen sinne ist doch garn nicht nötig. die datensätze werden in der reihenfolge des indexes ja sowieso sortiert. durch den b-tree geht das ja dann sehr zügig und entweder geht er halt von hinten heran oder von vorne…

ich hab bisher noch nie die notwendigkeit gesehen, einen index zu sortieren (arbeite auch mit der db2 auf einer iSeries).

cu tb.

Hi

Die Datenbank wurde nicht von mir entwickelt. Eine Notwendigkeit der Sortierung wollte ich (in diesem speziellen Fall) nicht in Frage stellen. Ich wollte diese lediglich nach PostgreSQL portieren. Da dort die Parameter ASC (Meines Wissens: ascending - aufsteigend) bei den Indexspalten angegeben waren ging ich davon aus, dass irgendjemand sich irgendetwas dabei gedacht haben sollte.

Nach deinen Informationen gebe ich dir aber recht. Aufgrund von B-tree erscheint es mir auch nicht mehr notwendig.

hi,

auch die db2 sollte b-tree verwenden. also keine ahnung was sich der ersteller gedacht bzw nicht gedacht hat. vielleicht fand er das einfach cool da noch ein ASC (= aufsteigend, deine aussage stimmt) einzufügen…

cu tb.

Hmm… Kann mich noch so an meine OpenIngres Performance-Schulung erinnern. Index zu sortieren mag durchaus Sinn machen (bei B-Tree vermutlich weniger), wenn oft Datenbereiche (von-bis) verwendet werden. Dann liegen die Daten direkt nebeneinander und es müssen weniger Blocks in den Cache geladen werden. Lohnt sich wohl aber erst bei sehr großen Datenmengen.

Bei B-Tree ist das aber IMHO nicht möglich (da von sich aus schon sortiert)