Телеграмм чат группы pgsql страница 9880

parrot.ru

Рейтинг популярных групп и каналов

В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

pgsql – PostgreSQL

4541 membersпожаловаться на группу

2020 May 28

l

lnuynxa in pgsql – PostgreSQL

Ребята, а как в postgresql оптимально, и главное правильно агрегировать данные, например
кол-во в каждой десятиминутке? (в таблице записан timestamp without timezone)

GROUP BY
https://stackoverflow.com/questions/7299342/what-is-the-fastest-way-to-truncate-timestamps-to-5-minutes-in-postgres

What is the fastest way to truncate timestamps to 5 minutes in Postgres?

Postgres can round (truncate) timestamps using the date_trunc function, like this:

date_trunc('hour', val)
date_trunc('minute', val)
I'm looking for a way to truncate a timestamp to the nearest 5-

источник

14:51пожаловаться #1

М

Максим in pgsql – PostgreSQL

GROUP BY
https://stackoverflow.com/questions/7299342/what-is-the-fastest-way-to-truncate-timestamps-to-5-minutes-in-postgres

What is the fastest way to truncate timestamps to 5 minutes in Postgres?

Postgres can round (truncate) timestamps using the date_trunc function, like this:

date_trunc('hour', val)
date_trunc('minute', val)
I'm looking for a way to truncate a timestamp to the nearest 5-

Спасибо

источник

14:52пожаловаться #2

YS

Yaroslav Schekin in pgsql – PostgreSQL

Ребята, а как в postgresql оптимально, и главное правильно агрегировать данные, например
кол-во в каждой десятиминутке? (в таблице записан timestamp without timezone)

Обычно используется date_trunc() или EXTRACT(EPOCH FROM ...) / date_part (+, возможно, to_timestamp())...
А, ответили уже...

> (в таблице записан timestamp without timezone)

А зря. Только что же обсуждали. ;)

источник

14:56пожаловаться #3

М

Максим in pgsql – PostgreSQL

Я знаю, Ярослав, мы и ранее с тобой обсуждали. Но очень опасно его менять....

источник

14:57пожаловаться #4

М

Максим in pgsql – PostgreSQL

я ж не могу сделать alter column для изменения типа данных и быть уверенным что ниче не полетит

источник

14:57пожаловаться #5

YS

Yaroslav Schekin in pgsql – PostgreSQL

Я знаю, Ярослав, мы и ранее с тобой обсуждали. Но очень опасно его менять....

Ну и вот даже в этом конкретном примере — с timestamp вариант "через epoch" уже без дополнительных "плясок" не работает, потому что to_timestamp() возвращает timestamptz.
Т.е. если аккуратно исполнять все эти "пляски"— работать можно... но зачем? ;)

источник

15:00пожаловаться #6

V💩

Vlad 💩 in pgsql – PostgreSQL

Ребята а есть ли смысл выносить поле из таблицы в другую таблицу которое в большинстве случает имеет null но нужно при каждом запросе? Допустим тот же soft delete мы можем создать поле deleted_at и deleted_by в таблице а можем вынести в отдельную таблицу эти поля, но если мы выносим нам все равно придется каждый раз джойнить и проверять в каких строках null что бы показывать только живые

источник

15:02пожаловаться #7

VY

Victor Yegorov in pgsql – PostgreSQL

Ребята а есть ли смысл выносить поле из таблицы в другую таблицу которое в большинстве случает имеет null но нужно при каждом запросе? Допустим тот же soft delete мы можем создать поле deleted_at и deleted_by в таблице а можем вынести в отдельную таблицу эти поля, но если мы выносим нам все равно придется каждый раз джойнить и проверять в каких строках null что бы показывать только живые

зависит от запросов. можно оставить, а для поиска создать ON (deleted_at) WHERE deleted_at IS NOT NULL индекс
такие индексы исользуются базой даже без явного указания предиката в `WHERE`-части запроса

источник

15:08пожаловаться #8

YS

Yaroslav Schekin in pgsql – PostgreSQL

Ребята а есть ли смысл выносить поле из таблицы в другую таблицу которое в большинстве случает имеет null но нужно при каждом запросе? Допустим тот же soft delete мы можем создать поле deleted_at и deleted_by в таблице а можем вынести в отдельную таблицу эти поля, но если мы выносим нам все равно придется каждый раз джойнить и проверять в каких строках null что бы показывать только живые

Если Вы имеете в виду именно вынос поля (а не разделение таблицы на таблицы актуальных и удалённых записей) — смысла в этом нет (по крайней мере, я не вижу ситуации, в которой это на самом деле было бы лучше).

источник

15:11пожаловаться #9

V💩

Vlad 💩 in pgsql – PostgreSQL

зависит от запросов. можно оставить, а для поиска создать ON (deleted_at) WHERE deleted_at IS NOT NULL индекс
такие индексы исользуются базой даже без явного указания предиката в `WHERE`-части запроса

хмм, а как быть тогда когда мне нужно будет показать удаленные? я смогу это сделать с таким индексом?

источник

15:14пожаловаться #10

VY

Victor Yegorov in pgsql – PostgreSQL

хмм, а как быть тогда когда мне нужно будет показать удаленные? я смогу это сделать с таким индексом?

SELECT * FROM tab WHERE deleted_at IS NOT NULL ?

источник

15:15пожаловаться #11

V💩

Vlad 💩 in pgsql – PostgreSQL

Yaroslav Schekin

Если Вы имеете в виду именно вынос поля (а не разделение таблицы на таблицы актуальных и удалённых записей) — смысла в этом нет (по крайней мере, я не вижу ситуации, в которой это на самом деле было бы лучше).

я имел ввиду вынос поля. А это как "разделение таблицы на таблицы актуальных и удалённых записей"? создавать 2 таблицы с одинаковым набором полей?

источник

15:16пожаловаться #12

VY

Victor Yegorov in pgsql – PostgreSQL

а какую задачу решаете?

источник

15:17пожаловаться #13

V💩

Vlad 💩 in pgsql – PostgreSQL

SELECT * FROM tab WHERE deleted_at IS NOT NULL ?

я просто не понимаю как отработает ваш индекс, если у меня почти везде нужно скрывать удаленные записи а потом в месте "Корзина" показывать.
EDIT
вот это часть не понятна "такие индексы исользуются базой даже без явного указания предиката в WHERE-части запроса"

источник

15:19пожаловаться #14

s0

shuu 01 in pgsql – PostgreSQL

есть ли разница с какой реплики в кластере снимать бэкап или лучше это делать всегда с мастера?

источник

15:20пожаловаться #15

l

lnuynxa in pgsql – PostgreSQL

есть ли разница с какой реплики в кластере снимать бэкап или лучше это делать всегда с мастера?

разве реплики создают WAL файлы?

источник

15:31пожаловаться #16

AN

Alexander Nikitin in pgsql – PostgreSQL

есть ли разница с какой реплики в кластере снимать бэкап или лучше это делать всегда с мастера?

Было выступление Сальникова на эту тему, про то, что не надо снимать бэкапы с реплик. На мой взгляд, если мониторинг настроен и видно, что реплики не отстают, то пусть снимается бэкап с реплики (я pg_probackup использовал).

источник

15:32пожаловаться #17

l

lnuynxa in pgsql – PostgreSQL

Alexander Nikitin

Было выступление Сальникова на эту тему, про то, что не надо снимать бэкапы с реплик. На мой взгляд, если мониторинг настроен и видно, что реплики не отстают, то пусть снимается бэкап с реплики (я pg_probackup использовал).

но речь идет только о полных бекапах?

источник

15:34пожаловаться #18

AN

Alexander Nikitin in pgsql – PostgreSQL

а что такое полный бэкап?

источник

15:34пожаловаться #19

YS

Yaroslav Schekin in pgsql – PostgreSQL

я имел ввиду вынос поля. А это как "разделение таблицы на таблицы актуальных и удалённых записей"? создавать 2 таблицы с одинаковым набором полей?

Да. Но это тоже совсем не радость (в плане последующего DDL и даже работы с этим всем), конечно.
Поэтому лучше просто не выносить.

источник

15:35пожаловаться #20