Re: Recognizing range constraints (was Re: Plan for relatively simple query seems to be very inefficient)
В списке pgsql-performance по дате отправления:
| От | a3a18850@telus.net |
|---|---|
| Тема | Re: Recognizing range constraints (was Re: Plan for relatively simple query seems to be very inefficient) |
| Дата | |
| Msg-id | 1112920211.4255d0934e23d@webmail.telus.net обсуждение исходный текст |
| Ответ на | Re: Recognizing range constraints (was Re: Plan for relatively simple query seems to be very inefficient) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-performance |
Quoting Tom Lane <tgl@sss.pgh.pa.us>: > Mischa <mischa.Sandberg@telus.net> writes: > > Quoting Tom Lane <tgl@sss.pgh.pa.us>: > >> WHERE a.x > b.y AND a.x < 42 > > > Out of curiosity, will the planner induce "b.y < 42" out of this? > > No. There's some smarts about transitive equality, but none about > transitive inequalities. Offhand I'm not sure if it'd be useful to add > such. The transitive-equality code pulls its weight [...] > but I'm less able to think of common use-cases for transitive > inequality ... Thanks. My apologies for not just going and looking at the code first. Equality-transitives: yes, worth their weight in gold. Inequality-transitivies: I see in OLAP queries (usually ranges), or in queries against big UNION ALL views, where const false inequalities are the norm. "a.x > b.y and a.x < c.z" comes up in OLAP, too, usually inside an EXISTS(...), where you are doing something analogous to finding a path.
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера