Re: Possible to improve optimisation / index usage based on domain properties of a function
От | Alban Hertroys |
---|---|
Тема | Re: Possible to improve optimisation / index usage based on domain properties of a function |
Дата | |
Msg-id | FAFD46C8-942F-48BC-895F-90F5D35D0DF2@gmail.com обсуждение исходный текст |
Ответ на | Re: Possible to improve optimisation / index usage based on domain properties of a function (Sameer Kumar <sameer.kumar@ashnik.com>) |
Ответы |
Re: Possible to improve optimisation / index usage based on domain properties of a function
|
Список | pgsql-general |
On 20 Feb 2014, at 7:21, Sameer Kumar <sameer.kumar@ashnik.com> wrote: > If however, I was to provide the below query, it uses a sequential scan based plan. The planner is unable to utilise anyindexes because it can’t know what the function is going to return – thus unable to constrain the range at the time ofplanning the execution. > > select count(*) from streams where date(stream_date) = ‘2013-01-08’; The inverse of that expression, if it’s possible to formulate one, would most likely use the index though: select count(*) from streams where stream_date = inv_date(‘2013-01-08’); > >> I’m wondering if we could build into postgres some level of metadata regarding the properties of a function, such thatthe optimiser could filter against the range of values that the function is expected to return. >> >> In this case, it could deduce that the date function will only ever return a value for stream_date to within a certainmaximum and minimum range. >> Thus the planner could scan the index for all values of stream_date falling within +/- 24 hours of the right operand,and then check/re-check the results. >> > If you can't go for the smarter query, go for more optimum index by "expression based index" > > http://www.postgresql.org/docs/9.1/static/indexes-expressional.html AFAIK, you can’t use expression based indexes to partition a table, so that won’t help the OP much. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest.
В списке pgsql-general по дате отправления: