Okay, ich biete:
AndreasCode:select distinct adresse, count(*) over (partition by adresse) as gesamt, count(*) over (partition by adresse,anschlussart) as anz, (100* count(*) over (partition by adresse,anschlussart)::numeric/count(*) over (partition by adresse))::numeric(5,2) as prozent, anschlussart from adresse order by adresse, anschlussart;
--
PostgreSQL Hosting
http://www.amazon.de/gp/registry/2APKFICAIYMWBads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
https://www.xing.com/profile/Andreas_Kretschmer7
Nachdem ich neugierigbin hab ich unsere Abfragen mal ueber eine "groessere" Tabelle rennen lassen. (Da ich das 'over' auch nicht kannte wollt ichs natuerlich genau wissen). Hab dazu die Tabelle mit dem PgScript gefuellt:
DECLARE @I, @T; -- Variable names begin with a @
SET @I = 0; -- @I is an integer
WHILE @I < 20000
BEGIN
INSERT INTO adresse VALUES ('München', 'Analog');
INSERT INTO adresse VALUES ('München', 'Analog');
INSERT INTO adresse VALUES ('München', 'Digital');
INSERT INTO adresse VALUES ('München', 'Sat');
INSERT INTO adresse VALUES ('München', 'Analog');
INSERT INTO adresse VALUES ('München', 'Analog');
INSERT INTO adresse VALUES ('Berlin', 'Digital');
INSERT INTO adresse VALUES ('Berlin', 'Digital');
INSERT INTO adresse VALUES ('Berlin', 'Digital');
INSERT INTO adresse VALUES ('Berlin', 'Sat');
SET @I = @I + 1;
END
Habe das Script dann abbrechen muessen, weil es immer langsamer geworden ist
Ergebnis mit 26750 Eintraegen:
mit 'over': 1331 ms, 3859 ms, 2055 ms.
ohne: 102 ms, 95 ms, 101 ms.
Hatte mir eigentlich genau das Gegenteil erwartet![]()
wenn man den ersten Typecast (numeric) durch real ersetzt gehts interessanter Weise mindestens doppelt so schnell (976 ms)
Sowas macht man in einer Transaktion. Du hast immer (automatisch) ein COMMIT gemacht, das ist teuer.
Gut, müßte man sich mal das EXPLAIN ANALYSE anschauen...Ergebnis mit 26750 Eintraegen:
mit 'over': 1331 ms, 3859 ms, 2055 ms.
ohne: 102 ms, 95 ms, 101 ms.
Hatte mir eigentlich genau das Gegenteil erwartet![]()
Andreas
--
PostgreSQL Hosting
http://www.amazon.de/gp/registry/2APKFICAIYMWBads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
https://www.xing.com/profile/Andreas_Kretschmer7
Deute ich das richtig, dass er die 'over' sequenziell abarbeitet?
Ich sehe kein EXPLAIN ANALYSE, was man könnte deuten. Ich sehe ein Script, welches z.B. eine Spalte mit 40% und 60% mit einem gleichen Wert füllt. Dies wird recht sicher immer zu einem Seq-Scan führen. Und ich sehe eine Abfrage ohne WHERE. Erwartest Du ernsthaft, dies ginge ohne einem Seq-Scan?
Andreas
--
PostgreSQL Hosting
http://www.amazon.de/gp/registry/2APKFICAIYMWBads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
https://www.xing.com/profile/Andreas_Kretschmer7
ok,
vielleicht habe ich die Frage falsch gestellt
Deute ich das richtig, dass er bei meiner Abfrage einige Dinge parallel durchfuehren kann?
Gerald
--
PostgreSQL Hosting
http://www.amazon.de/gp/registry/2APKFICAIYMWBads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
https://www.xing.com/profile/Andreas_Kretschmer7
Danke jungs!
Lass ich den Typecast weg geht es.Code:FEHLER: Syntaxfehler bei »:« LINE 1: ... count(*) over (partition by adresse,anschlussart):numeric/c...
--
PostgreSQL Hosting
http://www.amazon.de/gp/registry/2APKFICAIYMWBads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
https://www.xing.com/profile/Andreas_Kretschmer7
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen