Re: mysterious difference in speed when combining two queries with OR
От | A. Kretschmer |
---|---|
Тема | Re: mysterious difference in speed when combining two queries with OR |
Дата | |
Msg-id | 20080423075810.GB8401@a-kretschmer.de обсуждение исходный текст |
Ответ на | mysterious difference in speed when combining two queries with OR (Hans Ekbrand <hans.ekbrand@sociology.gu.se>) |
Ответы |
Re: mysterious difference in speed when combining two queries with OR
Re: mysterious difference in speed when combining two queries with OR |
Список | pgsql-performance |
am Wed, dem 23.04.2008, um 9:23:07 +0200 mailte Hans Ekbrand folgendes: > I cannot understand why the following two queries differ so much in execution time (almost ten times) wild guess: different execution plans. Can you show us the plans? (EXPLAIN ANALYSE SELECT ...) > > Query A (two queries) > > select distinct moment.mid from moment,timecard where parent = 45 and (pid=17 and timecard.mid = moment.mid) order by moment.mid; > select distinct moment.mid from moment,timecard where parent = 45 and (pbar = 0) order by moment.mid; > > Query B (combining the two with OR) > > select distinct moment.mid from moment,timecard where parent = 45 and ((pid=17 and timecard.mid = moment.mid) or (pbar= 0)) order by moment.mid; > > [ snip ] > > I should say that this is on postgresql 7.4.16 (debian stable). Uhh. Why not a recent version? We have 8.3.0... > > Can query B be rewritten so that it would execute faster? Quick and dirty: use both selects (query A) combined with UNION. I guess, with a recent version the planner can use a bitmap index scan to perform Query B faster. Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header) GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net
В списке pgsql-performance по дате отправления: