Re: [PERFORM] Anti join miscalculates row number?

2011-10-31 Thread Jens Reufsteck
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

[PERFORM] Anti join miscalculates row number?

2011-10-26 Thread Jens Reufsteck
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

[PERFORM] Performance issue with nested loop

2007-08-29 Thread Jens Reufsteck
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

[PERFORM] Performance issue with nested loop

2007-08-29 Thread Jens Reufsteck
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