разжуйте, я не против постыдиться

а зачем мне для каждого часа отдельные записи? Которые будут отличаться как раз этим одним числом...

Зачем, что реляционное моделирование выполняется именно так, а выполняется оно так потому, что у такого подхода есть преимущества (в том числе и то, что запросы для решения простых задач обычно получаются простые, кстати) описанные в каждом учебнике по реляционным базам данных. Соответственно, в реляционной СУБД по умолчанию стоит использовать именно его.

а если у меня будет 300 людей в один день работать в полную смену (8 часов), то у меня на один день будет записано 2400 записей?

А с массивами это как получается (Вы же показали только пример данных, не то, что они означают)?

В данный момент, если у меня к примеру 300 людей будуть работать в один день в полную смену, то будет 300 записей. Как-то так. Я извиняюсь что туплю возможно, только начал учить в университете бд..

вот

Да, тогда будет 2400 записей, получается.

но ваш метод будет правильней, да?
Тогда зачем вообще массивы в реляционной базе данных, если все надо через связи делать? 🤔

привет! кто знает, как установить plpython на macos? под линуксом все понятно, есть отдельный пакет, а под макосью нету и

brew install postgres --with-python

не работает больше (

Чтобы хранить массивы, очевидно?

невероятно, тогда можно сказать, что моя таблица имеет право на жизнь. Да?)

brew install postgres --with-python

Попробовать скомпилировать расширение самостоятельно. Но отсутствие пакета прозрачно намекает, что с этим будут сложности.

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

О-хо-хо. Итак:

1. "Два":

> PostgreSQL has the ability to report the progress of certain commands during command execution.

И ещё раз:

> Whenever VACUUM is running, the pg_stat_progress_vacuum view will contain one row for each backend (including autovacuum worker processes) that is currently vacuuming.

Не до или после, а только во время исполнения, обратите внимание.

2. И ещё "два":

> To start a single-user mode server, use a command like <skip>

> When invoked in single-user mode from the shell, the user can enter queries and the results will be printed to the screen, but in a form that is more useful for developers than end users. In the single-user mode, the session user will be set to the user with ID 1, and implicit superuser powers are granted to this user.

> Single-user mode also does not do any background processing, such as automatic checkpoints or replication.

Т.е. в single-user mode есть одна и только одна сессия, и это сам сервер, и с пользователем взаимодействует именно он.

Если сложить "два" и "два", получится четыре, что так как сессия только одна, и она выполняет все команды, в т.ч. и VACUUM, то посмотреть pg_stat_progress_vacuum во время его выполнения просто неоткуда (нет и не может быть другой сессии, откуда  можно было бы выполнить "SELECT ... FROM pg_stat_progress_vacuum").

> разжуйте, я не против постыдиться

Ну как оно, стыдно теперь? И ведь я Вас за язык не тянул. ;(

читаю...

неее, мы опять разошлись в разные стороны

в общем я посмотрел не туда, и неверно посчитал что вопрос касался того, работает ли ограничение в 1GB в single-user-mode. а не про обращение к стат вьюхе.

пока вы писали ответ, я шерстил код и в целом пришел к выводу что ограничение будет действительно и в single-user-mode.

А возвращаясь к просмотру вьюхи в SUM, то да согласен оно там не будет работать.

в общем не туда посмотрел, но в целом мне не стыдно )))

но круто что вы не ленитесь писать такие подробные портянки, это прям респект