Datenbank Designe Performance??

Unix-Tom

http://de.wikipedia.org/wiki/Datenbankindex

Gibst DU die 500.000 zurück?
Wenn ja kannst du nicht von 4 Sekunden für die DB ausgehen.
Die Übertragung dauert ja länger.
Zähle einfach die Datensätze. Hole dir mit where eingie heraus und mache ein COUNT()

Dann weiß t du wie lange ungefähr das RDBMS braucht um die Daten zu suchen.
Weiß nicht ob PostG. da was Onboard hat. Bei MSSQL kann man das testen lassen.

Performancer schrieb:

Hmm was bewirken den die indexe genau?

Naja grob gesagt repräsentieren sie deine Datensätze anhand von B-Bäumen. Bäume haben halt die nette Eigenschaft, dass Suchen immer relativ schnell geht. Sie haben aber auch die andere Eigenschaft, dass Änderungen am Baum aber im Vergleich zu anderen Datenstrukturen wieder eher langsam sind.

Siehe eben auch Unix-Toms vorhergehendes Posting.

ok danke schonmal und zwar folgendes:

die Tabelle (4 mill. datensätze):

CREATE TABLE t_loggingdata
(
  mytimestamp timestamp without time zone DEFAULT now(),
  timeid bigserial NOT NULL,
  "type" integer,
  typeval double precision,
  CONSTRAINT "TimeKeyID" PRIMARY KEY (timeid)
)

INDEX:

CREATE INDEX "TimeIDIndex"
  ON t_loggingdata
  USING btree
  (timeid);

mach ich nun ne query:

SELECT * FROM t_loggingData WHERE timeid > 100000 AND timeid < 500100;

wird hier nun auf den index zurückgegriffen oder muss man das angeben irgendwie?

Unix-Tom

PRIMK haben automatisch einen Index.
Deine Abfrage sollte sehr sehr schnell gehen.

naja bei den 500.000 datensätze die ich da selektiere geht es 15 sek.

noch was... bewirkt ein Index über mehrer spalten was?

wenn ich bspw. oben in meiner tabelle alle werte mit Typx im bereich ID 100000 bis 5000000 suchen will?

Hallo,

es gibt noch andere Möglichkeiten Postgres zu tunen.

1. Postgres hat einen Query-Optimizer, d.h. verschiedene sql-abfragen, können intern die gleichen Operationen auslösen, z.B. verschieden-implementierte Cross-Joins. Im Endeffekt entscheidet die hinterlegende Struktur & Indizierung über die Performance.

2. Postgres hat ein komplexes Caching-System.
Da gibts u.a. den Disk-Cache und nochmal Caches für jeden postgres-Prozess und vielleicht wichtig zu erwähnen den "Query-Cache". Insbesondere wenn die Datenmengen größer sind, ist es wichtig, wenn sie noch in diesen Cache passen ... standard glaub ich 1MB <--- !

Ich hatte mal den Fall von ca. 1.000.000 Inserts in einem Statement(transaction), nachdem ich den Query-Cache hochgestellt hab, liefs besser als 100mal 10.000 Inserts zu machen. ( interessant oder ?)

Schau mal in der Richtung weiter ... und check mal die Größenordnungen deiner SQL-Operation. Wenn du es schaffst, alle Operation im Cache ablaufen zu lassen, bist du in der Hinsicht auf der sicheren Seite.

Für kommerzielle Projekte gibts auch die Möglichkeit Postgres-Entwickler "zu mieten". Die tunen dann die DB oder Debuggen deine Postgres-Plugins.

PostgresGreetz

Danke PostGreFan,

ich hab grad ein andere Problem.. ich fülle grad die Table (siehe oben t_loggingdata) mit daten... über INSERT query.

nun kommt ein fehler wenn i== 30.000.015 groß ist

for (long i = 0; i < 100000000; i++)
                {
                    command.CommandText = "INSERT INTO T_LoggingData(Type,TypeVal) Values (" + (i % 50) + "," + (float)(i / 3) + ")";
                    command.ExecuteNonQuery();
                    Console.WriteLine("Record {0}", i);
                }

ERROR [42601] ERROR: INSERT has more expressions than target columns;
Error while executing the query

versteh das nich:(

Problem oben gelöst:)

Aber wie erhöhe ich den diskcache bzw. den Query- cache?

Findest du alles in der Doku, ansonsten schau mal in die Postgres-Config-Files.