Re: On partitioning
От | Claudio Freire |
---|---|
Тема | Re: On partitioning |
Дата | |
Msg-id | CAGTBQpZSEvcvr_CHu=kWhapqWNjXCH+zbFPY5ybcPjJt32MpCA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: On partitioning (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: On partitioning
|
Список | pgsql-hackers |
On Tue, Dec 16, 2014 at 12:15 PM, Robert Haas <robertmhaas@gmail.com> wrote: > <Langote_Amit_f8@lab.ntt.co.jp> wrote: >> Robert wrote: >>> On Sun, Dec 14, 2014 at 9:12 PM, Amit Langote >>> <Langote_Amit_f8@lab.ntt.co.jp> wrote: >>> > This means if a user puts arbitrary expressions in a partition definition, say, >>> > >>> > ... FOR VALUES extract(month from current_date) TO extract(month from >>> current_date + interval '3 months'), >>> > >>> > we make sure that those expressions are pre-computed to literal values. >>> >>> I would expect that to fail, just as it would fail if you tried to >>> build an index using a volatile expression. >> >> Oops, wrong example, sorry. In case of an otherwise good expression? > > I'm not really sure what you are getting here. An "otherwise-good > expression" basically means a constant. Index expressions have to be > things that always produce the same result given the same input, > because otherwise you might get a different result when searching the > index than you did when building it, and then you would fail to find > keys that are actually present. I think the point is partitioning based on the result of an expression over row columns. Or if it's not, it should be made anyway: PARTITION BY LIST (extract(month from date_created) VALUES (1, 3, 6, 9, 12); Or something like that.
В списке pgsql-hackers по дате отправления: