Thread: [pgsql-ru-general] Темпоральные данные в PostgreSQL

[pgsql-ru-general] Темпоральные данные в PostgreSQL

From
Pavel Drankov
Date:
Привет всем,

Я хотел бы узнать, какие возможности имеются в PostgreSQL для работы с темпоральными данными. Хотелось бы получить некий обзор или место в документации, где про это можно прочесть.

Best wishes,
Pavel

[pgsql-ru-general] Re: [pgsql-ru-general] Темпоральные данные в PostgreSQL

From
Nikolay Samokhvalov
Date:
В ядрес спецсредств для темпоральных данных как таковых нет, но есть много всяких работ/проектов "вокруг"

https://wiki.postgresql.org/images/6/64/Fosdem20150130PostgresqlTemporal.pdf









2017-09-23 3:50 GMT-07:00 Pavel Drankov <titantins@gmail.com>:
Привет всем,

Я хотел бы узнать, какие возможности имеются в PostgreSQL для работы с темпоральными данными. Хотелось бы получить некий обзор или место в документации, где про это можно прочесть.

Best wishes,
Pavel

[pgsql-ru-general] Re: [pgsql-ru-general] Темпоральные данные в PostgreSQL

From
Nikolay Samokhvalov
Date:
Забыл, есть ещё вот такая штука https://github.com/timescale/timescaledbhttps://blog.timescale.com/when-boring-is-awesome-building-a-scalable-time-series-database-on-postgresql-2900ea453ee2 -- сейчас активно развивается

2017-09-23 10:51 GMT-07:00 Nikolay Samokhvalov <samokhvalov@gmail.com>:
В ядрес спецсредств для темпоральных данных как таковых нет, но есть много всяких работ/проектов "вокруг"

https://wiki.postgresql.org/images/6/64/Fosdem20150130PostgresqlTemporal.pdf









2017-09-23 3:50 GMT-07:00 Pavel Drankov <titantins@gmail.com>:
Привет всем,

Я хотел бы узнать, какие возможности имеются в PostgreSQL для работы с темпоральными данными. Хотелось бы получить некий обзор или место в документации, где про это можно прочесть.

Best wishes,
Pavel


Добавлю, но полностью не уверен.

К категории работы с временными данными отношу, также, Materialized
views in PostgreSQL
https://www.postgresql.org/docs/current/static/rules-materializedviews.html
.

Были случаи, когда нужно на время фиксировать некие наборы данных и
возникали мысли скидывать их во временные таблицы, но потом узнал про
материализованные представления и многое упростилось. Сохраняю такие
представления во временную схему, но как угодно. Слава ПГ!

23.09.2017, Pavel Drankov<titantins@gmail.com> написал(а):
> Привет всем,
>
> Я хотел бы узнать, какие возможности имеются в PostgreSQL для работы с
> темпоральными данными. Хотелось бы получить некий обзор или место в
> документации, где про это можно прочесть.
>
> Best wishes,
> Pavel
>


-- 
---
С уважением,
Михаил Наседкин

--
Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ru-general

Большое спасибо за информацию!

Best wishes,
Pavel

2017-09-27 9:48 GMT+03:00 Михаил <m.nasedkin@gmail.com>:
Добавлю, но полностью не уверен.

К категории работы с временными данными отношу, также, Materialized
views in PostgreSQL
https://www.postgresql.org/docs/current/static/rules-materializedviews.html
.

Были случаи, когда нужно на время фиксировать некие наборы данных и
возникали мысли скидывать их во временные таблицы, но потом узнал про
материализованные представления и многое упростилось. Сохраняю такие
представления во временную схему, но как угодно. Слава ПГ!

23.09.2017, Pavel Drankov<titantins@gmail.com> написал(а):
> Привет всем,
>
> Я хотел бы узнать, какие возможности имеются в PostgreSQL для работы с
> темпоральными данными. Хотелось бы получить некий обзор или место в
> документации, где про это можно прочесть.
>
> Best wishes,
> Pavel
>


--
---
С уважением,
Михаил Наседкин

> К категории работы с временными данными отношу, также, Materialized
> views in PostgreSQL
> https://www.postgresql.org/docs/current/static/rules-materializedviews.html
> .

> Были случаи, когда нужно на время фиксировать некие наборы данных и
> возникали мысли скидывать их во временные таблицы, но потом узнал про
> материализованные представления и многое упростилось. Сохраняю такие
> представления во временную схему, но как угодно. Слава ПГ!


я с этим механизмом не работал еще, но очень интересно.

скажите: вот например имеется таблица 1-10 млн записей и таблица
скажем 2000 записей.

создаем материализованное представление, со скажем GROUP BY или там
просто что-то по 10 млн и по 2000.

Вопрос: процесс создания будет блокировать БД или нет?
для CREATE INDEX придумали CONCURRENTLY без которого на реальном
продакшене вообще никуда уже не сунуться,
а вот с материализованными представлениями как дела обстоят в этом
смысле?

вижу что есть REFRESH MATERIALIZED VIEW CONCURRENTLY, но не вижу
CREATE: оно будет блокать БД, правильно понимаю?
--

. ''`.            Dmitry E. Oboukhov <unera@debian.org>
: :’  :
`. `~’               GPG key: 4096R/08EEA756 2014-08-30 `- 71ED ACFC 6801 0DD9 1AD1  9B86 8D1F 969A 08EE A756

On 27.09.2017 11:02, Dmitry E. Oboukhov wrote:
> вижу что есть REFRESH MATERIALIZED VIEW CONCURRENTLY, но не вижу
> CREATE: оно будет блокать БД, правильно понимаю?
Без CONCURRENTLY будет блокировать запросы к мат. представлению, которых 
не должно быть до CREATE.

В любом случае, можно:
CREATE MATERIALIZED VIEW ... WITH NO DATA;
REFRESH MATERIALIZED VIEW CONCURRENTLY;

-----
Pavel Luzanov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



-- 
Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ru-general

>> вижу что есть REFRESH MATERIALIZED VIEW CONCURRENTLY, но не вижу
>> CREATE: оно будет блокать БД, правильно понимаю?
> Без CONCURRENTLY будет блокировать запросы к мат. представлению, которых не
> должно быть до CREATE.

> В любом случае, можно:
> CREATE MATERIALIZED VIEW ... WITH NO DATA;
> REFRESH MATERIALIZED VIEW CONCURRENTLY;

ага, понял. надо будет попробовать поиграть с этим механизмом :)
--

. ''`.            Dmitry E. Oboukhov <unera@debian.org>
: :’  :
`. `~’               GPG key: 4096R/08EEA756 2014-08-30 `- 71ED ACFC 6801 0DD9 1AD1  9B86 8D1F 969A 08EE A756

[pgsql-ru-general] Re: [pgsql-ru-general] Темпоральные данные в PostgreSQL

From
Nikolay Samokhvalov
Date:
On Wednesday, September 27, 2017, Pavel Luzanov <p.luzanov@postgrespro.ru> wrote:
On 27.09.2017 11:02, Dmitry E. Oboukhov wrote:
вижу что есть REFRESH MATERIALIZED VIEW CONCURRENTLY, но не вижу
CREATE: оно будет блокать БД, правильно понимаю?
Без CONCURRENTLY будет блокировать запросы к мат. представлению, которых не должно быть до CREATE.

В любом случае, можно:
CREATE MATERIALIZED VIEW ... WITH NO DATA;
REFRESH MATERIALIZED VIEW CONCURRENTLY;

Паша, так, конечно, не заработает. Кое-чего не хватает ;) 

On 27.09.2017 16:40, Nikolay Samokhvalov wrote:

В любом случае, можно:
CREATE MATERIALIZED VIEW ... WITH NO DATA;
REFRESH MATERIALIZED VIEW CONCURRENTLY;

Паша, так, конечно, не заработает. Кое-чего не хватает ;) 
Был неправ, вспылил))
Действительно не сработает:
postgres=# create materialized view m as select * from t with no data;
SELECT 0
postgres=# refresh materialized view CONCURRENTLY m;
ERROR:  CONCURRENTLY cannot be used when the materialized view is not populated

-----
Pavel Luzanov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
2017-09-27 7:15 GMT-07:00 Pavel Luzanov <p.luzanov@postgrespro.ru>:

On 27.09.2017 16:40, Nikolay Samokhvalov wrote:

В любом случае, можно:
CREATE MATERIALIZED VIEW ... WITH NO DATA;
REFRESH MATERIALIZED VIEW CONCURRENTLY;

Паша, так, конечно, не заработает. Кое-чего не хватает ;) 
Был неправ, вспылил))
Действительно не сработает:
postgres=# create materialized view m as select * from t with no data;
SELECT 0
postgres=# refresh materialized view CONCURRENTLY m;
ERROR:  CONCURRENTLY cannot be used when the materialized view is not populated

вот-вот + ещё индекс уникальный нужен будет

> вот-вот + ещё индекс уникальный нужен будет

> -i used with no filenames on the command line, reading from STDIN.

так я не понял: можно неблокирующе VIEW построить по таблице о N млн
записей?
--

. ''`.            Dmitry E. Oboukhov <unera@debian.org>
: :’  :
`. `~’               GPG key: 4096R/08EEA756 2014-08-30 `- 71ED ACFC 6801 0DD9 1AD1  9B86 8D1F 969A 08EE A756