update Befehl mit select in where Bedingung

Ok, danke für die direkte Antwort. Jetzt verstehe ich auch auf was du raus wolltest. Damit habe ich mich schon befasst, aber eben den Begriff Sequentiell wahrscheinlich überlesen.
Ich weiß einigermaßen Bescheid über das Verfahren mit den Indexen und deren Vor und Nachteilen. MyIsam ist ja auf 3 Dateien aufgebaut . In der Datei *.MYI befinden sich Laienhaft gesagt die Schlüssel.
Ich habe mich auch ein bisschen mit dem Suchalgortihmus auseinander gesetzt.

Da der Eintrag eben genau 1 mal in der Spalte vorkommt, ist meiner Erkenntnis (bis jetzt) der Index das richtige. Oder liege ich da falsch
 
Werbung:
ja.. tut es leider nicht.. aber eventuell habe ich ja einen Fehler beim erstellen des Index..
in die Verfahren Btree, Rtree oder Hash muss ich mich erst noch einlesen.. Diese stehen mir nämlich zur Auswahl, sowahl auch die Key Block Size.
 
ja.. tut es leider nicht.. aber eventuell habe ich ja einen Fehler beim erstellen des Index..
in die Verfahren Btree, Rtree oder Hash muss ich mich erst noch einlesen.. Diese stehen mir nämlich zur Auswahl, sowahl auch die Key Block Size.

BTREE ist schon okay:

Code:
test=# create table chris(id serial primary key, ts timestamp, val numeric default random());
CREATE TABLE
test=*# insert into chris (ts) select '2010-01-01'::timestamp + s * '5 minutes'::interval from generate_series(1, 10000000) s;
INSERT 0 10000000
test=*#
test=*# create index idx_1 on chris (ts);
CREATE INDEX
test=*# analyse chris;
ANALYZE
test=*# explain select * from chris where ts between '2010-04-04 00:00:00' and '2010-04-04 00:30:00';
  QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_1 on chris  (cost=0.43..8.55 rows=6 width=23)
  Index Cond: ((ts >= '2010-04-04 00:00:00'::timestamp without time zone) AND (ts <= '2010-04-04 00:30:00'::timestamp without time zone))
(2 rows)

Hash-Indexe helfen hier nicht, die Doku sagt: "Hash indexes can only handle simple equality comparisons."

Code:
test=*# drop index idx_1;
DROP INDEX
test=*# create index idx_1 on chris using hash (ts);
CREATE INDEX
test=*# explain select * from chris where ts between '2010-04-04 00:00:00' and '2010-04-04 00:30:00';
  QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------
 Seq Scan on chris  (cost=0.00..223530.00 rows=6 width=23)
  Filter: ((ts >= '2010-04-04 00:00:00'::timestamp without time zone) AND (ts <= '2010-04-04 00:30:00'::timestamp without time zone))
(2 rows)

Hier sieht man das Kostenmodell von PostgreSQL bei der Arbeit ;-)


RTREE-Indexe hat PostgreSQL nicht, weil:


  • Remove R-tree indexing (Tom)

    Rtree has been re-implemented using GiST
(Auszug aus den Release Notes).

GiST-Index würde Dir hier aber auch nicht helfen, die sind für solche Fälle wie hier beschrieben: http://www.postgresql.org/docs/9.4/static/textsearch-indexes.html und http://www.postgresql.org/docs/9.4/static/gist-builtin-opclasses.html#GIST-BUILTIN-OPCLASSES-TABLE. Damit kannst Du so nette Sachen wie eine Umkreissuche indexieren.
 
Vielen Dank für deine Hilfe! Ich werde mich da nochmal einlesen und auch nochmal auf die Antwort von BerndB warten. Bis dahin versuche ich mich noch ein bisschen detailierter in die Sache reinzulesen. denn ich habe auch noch festgestellt das die ADODB Schnittstelle die ich benutze 14s braucht um ein Array von 3x500.000 Werten zu holen. dh ich bin bei insgesamt 17 sekunden um die Daten dann zu parsen und anzuzeigen.
Das ist nicht akzeptabel
 
Werbung:
Hi Chris,

bi jetzt zu Hause und wir könnten loslegen.

Du kannst mich gerne heute noch bis 23:30 anrufen, dann erzähl ich dir was dazu

02163 / 5719653

Gruss

Bernd
 
Zurück
Oben