Schön, daß man sich in diesen Foren noch normal unterhalten kann. Sehr schön.
- Clustering Ich würde halt gerne ohne zusätzlichen Anbieter auskommen. Wäre halt schön, wenn PgSQL das irgendwann selbst unterstützt...aber ich denke das wird schon.
- Replikation Bin mal gespannt was Slony so bringt. eRserver ist ganz nett aber bspw. mit Oracle nicht zu vergleichen. Mit MySQL vergleiche ich schonmal überhaupt nicht - das machen schon die Politiker (sie nach unten orientieren)
- REDO/UNDO Interessant.
- Shadow tables Es wäre halt schön bspw. in einer GUI eine Änderungshistorie einfach anzuzeigen und der User könnte dann einen alten Stand mit zwei Mausklicks wieder herstellen. Aber wie Du schon sagst - ein Sahnehäubchen :)
- Raw devices Mit der Portabilität mag das schon stimmen. Es müsste halt optional sein. Verwende das PgSQL derzeit auf einer XFS-Partition (noatime,nodiratime) und bin eigentlich relativ zufrieden damit.
- Updatebare Views Genau - ohne CREATE RULE. Einen View einfach so updaten als wäre es eine normale Tabelle. Oracle z.B. kann das imho - bei PgSQL gibt es dazu auch des öfteren Überlegungen. Mal sehen...kommen wirds irgendwann ganz sicher.
- Aggregation Gerade GROUP BY ... LIMIT bei größeren Tabellen bei denen man nur die ersten (nach der Gruppierung) 10 Datensätze braucht dauert manchmal schon recht lang. Meist kann man dies aber durch aufsplitten der Tabellen kompensieren.
- PITR ...stimmt, das wäre auch ein sehr schönes (und für den großen Einsatz auch wichtiges) Feature.
- 2-Phase Commit ...sagt mir nicht besonders viel, liesse sich doch mit Nested Transactions (schön wenn es die gäbe) realisieren, oder?
- Updateable Views Views beruhen in PostgreSQL ja immer auf einem CREATE RULE. Was man tun müsste, diese auch automatisch updateable zu machen, wäre implicit die jeweiligen Rules für den Update der jeweiligen Table zu erstellen (also beim CREATE VIEW)....
- Aggregationen: Zu deinem Beispiel: in 7.4 hat sich diesbezüglich mit den neuen Hash Aggregates einiges getan. Aber wenn du wirklich grosse Datenmengen hast.... Das grösste Handicap hat aber momentan count(*), da dies in PG _immer_ einen table scan erfordert....
- 2 Phase Commit: Das ist ein Verfahren für verteilte Transaktionen, allgemein: (Phase 1): System A fragt an System B,C,D an, ob sie für einen COMMIT bereit sind. Diese erledigen dann die Transaktion(en) (muss nicht sofort sein). System A koordiniert diese Transaktion(en) und hält fest, das alle zum COMMIT bereit sind/waren. (Phase 2): System A informiert nun alle beteiligten Systeme über die Entscheidung (COMMIT oder ROLLBACK). Diese machen einen COMMIT und fertig.
- Clustering
Ich würde halt gerne ohne zusätzlichen Anbieter auskommen. Wäre halt schön, wenn PgSQL das irgendwann selbst unterstützt...aber ich denke das wird schon.
- Replikation
Bin mal gespannt was Slony so bringt. eRserver ist ganz nett aber bspw. mit Oracle nicht zu vergleichen. Mit MySQL vergleiche ich schonmal überhaupt nicht - das machen schon die Politiker (sie nach unten orientieren)
- REDO/UNDO
Interessant.
- Shadow tables
Es wäre halt schön bspw. in einer GUI eine Änderungshistorie einfach anzuzeigen und der User könnte dann einen alten Stand mit zwei Mausklicks wieder herstellen. Aber wie Du schon sagst - ein Sahnehäubchen :)
- Raw devices
Mit der Portabilität mag das schon stimmen. Es müsste halt optional sein. Verwende das PgSQL derzeit auf einer XFS-Partition (noatime,nodiratime) und bin eigentlich relativ zufrieden damit.
- Updatebare Views
Genau - ohne CREATE RULE. Einen View einfach so updaten als wäre es eine normale Tabelle. Oracle z.B. kann das imho - bei PgSQL gibt es dazu auch des öfteren Überlegungen. Mal sehen...kommen wirds irgendwann ganz sicher.
- Aggregation
Gerade GROUP BY ... LIMIT bei größeren Tabellen bei denen man nur die ersten (nach der Gruppierung) 10 Datensätze braucht dauert manchmal schon recht lang. Meist kann man dies aber durch aufsplitten der Tabellen kompensieren.
- PITR
...stimmt, das wäre auch ein sehr schönes (und für den großen Einsatz auch wichtiges) Feature.
- 2-Phase Commit
...sagt mir nicht besonders viel, liesse sich doch mit Nested Transactions (schön wenn es die gäbe) realisieren, oder?
Views beruhen in PostgreSQL ja immer auf einem CREATE RULE. Was man tun müsste, diese auch automatisch updateable zu machen, wäre
implicit die jeweiligen Rules für den Update der jeweiligen Table zu erstellen (also beim CREATE VIEW)....
- Aggregationen:
Zu deinem Beispiel: in 7.4 hat sich diesbezüglich mit den neuen Hash Aggregates einiges getan. Aber wenn du
wirklich grosse Datenmengen hast....
Das grösste Handicap hat aber momentan count(*), da dies in PG _immer_ einen table scan erfordert....
- 2 Phase Commit:
Das ist ein Verfahren für verteilte Transaktionen, allgemein:
(Phase 1): System A fragt an System B,C,D an, ob sie für einen COMMIT bereit sind.
Diese erledigen dann die Transaktion(en) (muss nicht sofort sein).
System A koordiniert diese Transaktion(en) und hält fest, das alle zum COMMIT bereit sind/waren.
(Phase 2): System A informiert nun alle beteiligten Systeme über die Entscheidung (COMMIT oder ROLLBACK). Diese machen einen COMMIT und fertig.