Re: [SQL] "SELECT IN" Still Broken in 7.4b
От | Tom Lane |
---|---|
Тема | Re: [SQL] "SELECT IN" Still Broken in 7.4b |
Дата | |
Msg-id | 28348.1061502363@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [SQL] "SELECT IN" Still Broken in 7.4b (Manfred Koizar <mkoi-pg@aon.at>) |
Ответы |
Re: [SQL] "SELECT IN" Still Broken in 7.4b
|
Список | pgsql-hackers |
Manfred Koizar <mkoi-pg@aon.at> writes: > WHERE a = 1 OR a = 2 > are totally different things. In the latter case you don't have to > check prior conditions because the conditions are mutually exclusive. > Is this reasonably easy to find out at plan creation time? Yeah, I know, but I see no easy way to verify this (where "easy" means "doesn't take an unreasonable amount of time"). A naive check would take O(N^2) time, putting you right back where you started. Even a smart check would surely take more time per item than one hashtable probe. I'm also concerned about how much the planner would have to assume about the semantics of the operators in order to prove the conditions are mutually exclusive. Finally, I suspect that once we get rid of the O(N^2) behavior in the executor, we will find that the next biggest bottleneck is in the planner; adding more work for it to do per OR-clause item will make things worse not better. regards, tom lane
В списке pgsql-hackers по дате отправления: