Re: [SQL] Simple Optimization Problem
От | Bruce Momjian |
---|---|
Тема | Re: [SQL] Simple Optimization Problem |
Дата | |
Msg-id | 199905100431.AAA23261@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Simple Optimization Problem (secret <secret@kearneydev.com>) |
Ответы |
Re: [SQL] Simple Optimization Problem
|
Список | pgsql-sql |
I have added this to our TODO list as: process const=const parts of OR clause first > I need to run a report using some parameters that are optional, I'm > doing this by labeling "0" as the optional value. IE here is a > simplified example: > > CREATE TABLE po (po_id int4 PRIMARY KEY, data text); > (insert a bunch of rows) > > ftc=> explain select * from po where po_id=8888; > NOTICE: QUERY PLAN: > > Index Scan using ipo_poid_units on po (cost=2.05 size=1 width=94) > > EXPLAIN > > ftc=> explain select * from po where (po_id=8888 or 0=8888); > NOTICE: QUERY PLAN: > > Seq Scan on po (cost=449.96 size=1751 width=94) > > EXPLAIN > > I was hoping PostgreSQL could optimize out the boolean condition > given in the where clause, but it causes it to disregard the index > instead of throwing out 0=8888 in the first stage. > > This is the only way I can think to do this, I have crystal reports > send through the SQL instead of doing the whole thing itself(Which > involves returning all possible rows... Sigh)... This query is taking 20 > minutes as a result... Is there any hope in 6.5 of the optimizer > handling this better? > > David Secret > MIS Director > Kearney Development Co., Inc. > > > -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-sql по дате отправления: