Re: truncating timestamps on arbitrary intervals

Поиск
Список
Период
Сортировка
От Salek Talangi
Тема Re: truncating timestamps on arbitrary intervals
Дата
Msg-id CACX8wBfHPKn7-2wo-32kTo_KQ5tsR_xvrFWDEUEzZZQw4CmcnQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: truncating timestamps on arbitrary intervals  (John Naylor <john.naylor@enterprisedb.com>)
Ответы Re: truncating timestamps on arbitrary intervals
Список pgsql-hackers
Hi all,

it might be a bit late now, but do you know that TimescaleDB already has a similar feature, named time_bucket?
Perhaps that can help with some design decisions.
I saw your feature on Depesz' "Waiting for PostgreSQL 14" and remembered reading about it just two days ago.

Best regards
Salek Talangi

Am Do., 1. Apr. 2021 um 13:31 Uhr schrieb John Naylor <john.naylor@enterprisedb.com>:
On Sat, Mar 27, 2021 at 1:06 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> The current docs seem to be missing a "synopsis", like
>
> +<synopsis>
> +date_trunc(<replaceable>stride</replaceable>, <replaceable>timestamp</replaceable>, <replaceable>origin</replaceable>)
> +</synopsis>

The attached 
- adds a synopsis 
- adds a bit more description to the parameters similar to those in date_trunc
- documents that negative intervals are treated the same as positive ones

Note on the last point: This just falls out of the math, so was not deliberate, but it seems fine to me. We could ban negative intervals, but that would possibly just inconvenience some people unnecessarily. We could also treat negative strides differently somehow, but I don't immediately see a useful and/or intuitive change in behavior to come of that.

--
John Naylor
EDB: http://www.enterprisedb.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zhihong Yu
Дата:
Сообщение: Re: Crash in BRIN minmax-multi indexes
Следующее
От: Amit Langote
Дата:
Сообщение: Re: ModifyTable overheads in generic plans