Just tested on 9.0.5, seems ok. Explain for the suspected sub query is now in
line with Analyze.
Thanks
Jens
"Jens Reufsteck" writes:
> I’ve got a lengthy query, that doesn't finish in reasonable time (i.e.
> 10min+). I suspect, that the query optimizer miscalculates the
niid | integer |
von | date |
bis | date |
unisonstige | character varying(128) |
unilandid | integer|
ausrichtungsonstige | character varying(64) |
vertiefungsonstige | character varying(64) |
qnoteid | integer|
status | smallint | not null Vorgabewert
1
Indexe:
"study_pkey" PRIMARY KEY, btree (studyid)
"study_sid_idx" btree (sid)
Fremdschlüssel-Constraints:
"study_sid_fkey" FOREIGN KEY (sid) REFERENCES stud(sid) ON UPDATE
CASCADE ON DELETE CASCADE
Fremdschlüsselverweise von:
TABLE "study_ausrichtung" CONSTRAINT "study_ausrichtung_studyid_fkey"
FOREIGN KEY (studyid) REFERENCES study(studyid) ON UPDATE CASCADE ON DELETE
CASCADE
TABLE "study_vertiefung" CONSTRAINT "study_vertiefung_fkey1" FOREIGN KEY
(studyid) REFERENCES study(studyid) ON UPDATE CASCADE ON DELETE CASCADE
Many thanks
--
Jens Reufsteck
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
as one table is affected.
They're much worse as soon as two or more tables are joined. Though the
query plans are slightly different, the number of merged rows at different
stages seems to be rather the same for both plans. The big difference in my
eyes seems the cost for the first nested l
as one table is affected.
They're much worse as soon as two or more tables are joined. Though the
query plans are slightly different, the number of merged rows at different
stages seems to be rather the same for both plans. The big difference in my
eyes seems the cost for the first nested l