это еще про UUID не вспомнили (36 человекопонятных символов vs 16 байт)

котики, не ссорьтесь >^..^<

надо в правила записать "не спрашивать у спецов по БД, что лучше Int, timestamp или datetime"

а так, если экономить место - иногда вдруг оказывается, что null-terminated текст занимает меньше, чем int, например

https://habrahabr.ru/company/mailru/blog/242645/ Интересная статейка.

и дальше чего

https://github.com/postgrespro/pg_oltp_bench.git видал такое

Или прямо писать тип timestamptz

прямо писать тип

только теперь без нуля

можно прямо timestamptz

Корче, он всеравно превращается в timestamp

ну да

как и float становится double precision

никто не в курсе, не запихнули ли яндексовые патчи в офф барман?

в курсе, нет, не запихнули (

как и float становится double precision

так он будет хранить временную зону?

точнее как он буджет хранить данные?

В 0 зоне?

? я хочу просто чтобы дата помнилась правильно в луюбом случае

он не хранит таймзону, но выводит и вводит её

он не хранит таймзону, но выводит и вводит её

а в какой тамзоне хранится дата?

я понимаю что не хранит

вот, например если будет декретное время (это когда + или - 1 час), тогда как быть?

хотя чего допустим. сейчас сменю время.

хотя чего допустим. сейчас сменю время.

https://github.com/postgres/postgres/blob/c7b8998ebbf310a156aa38022555a24d98fdbfb4/src/interfaces/ecpg/pgtypeslib/timestamp.c#L34

а в какой тамзоне хранится дата?

utc?

https://github.com/postgres/postgres/blob/c7b8998ebbf310a156aa38022555a24d98fdbfb4/src/interfaces/ecpg/pgtypeslib/timestamp.c#L34

?я не хочу руками менять время.

Таймстамп сам по себе не может иметь таймзоны, насколько понимаю, он просто может быть сконвертирован в/из даты с таймзоной, а сама необходимость в ПГ происходит из того, что ему заранее надо знать, может ли быть таймзона в том, что надо будет парсить.

Таймстамп сам по себе не может иметь таймзоны, насколько понимаю, он просто может быть сконвертирован в/из даты с таймзоной, а сама необходимость в ПГ происходит из того, что ему заранее надо знать, может ли быть таймзона в том, что надо будет парсить.

То есть хранится типа unixtime

просто отображается как тебе уже надо

Я попробую использовать timestamp в новой БД, но до конца не понимаю

Так, я по диагонали прочитал доку, и это не очень ок. Постгре действительно нужно знать, что он читает timestamp with tz, чтобы правильно распарсить, но сам тип описан в стандарте SQL, и я беглым поиском не нашел, что это такое. Тем не менее, по доке постгре он хранится ровно так же, и никакого реального смысла в таймзоне для таймстампа я не вижу.

ситуация следующая: я в поле __md по дефолту пишу now() Дефолт выдает текущее время в зоне +3 (то есть 16:58) Меняю часовой пояс (на +4), перезапускаю сервер, всеравно выводит 16:58)

Так, я по диагонали прочитал доку, и это не очень ок. Постгре действительно нужно знать, что он читает timestamp with tz, чтобы правильно распарсить, но сам тип описан в стандарте SQL, и я беглым поиском не нашел, что это такое. Тем не менее, по доке постгре он хранится ровно так же, и никакого реального смысла в таймзоне для таймстампа я не вижу.

у них разные in/out.

ситуация следующая: я в поле __md по дефолту пишу now() Дефолт выдает текущее время в зоне +3 (то есть 16:58) Меняю часовой пояс (на +4), перезапускаю сервер, всеравно выводит 16:58)

Где меняете часовой пояс? Какой сервер перезапускаете, может сервис?

Либо он помнит это в UTC и принимает в UTC и когда я отправил +3 он посчитал это как UTC, либо что-то неправильно работает

Где меняете часовой пояс? Какой сервер перезапускаете, может сервис?

да, сервис

Postgres если конкретно

меняю часовой пояс на локальной машине (там же Postgres развернут)

меняю часовой пояс на локальной машине (там же Postgres развернут)

насколько я знаю нужно менять в конфиге потгрес

жаль. я хочу хранить и выврдить всегда при любом дампе, на любом червере, при любой ситуации по дефолту UTC

И не париться на счет часового пояса. На бэкенде я уж как нибудь сам отрегулирую вывод информации.

а если при каждом удобном случае надо будет костыли городить и придумывать как выести "честное" время, то для меня (вохможно из-за моего непонимания) timestamp пока что сомнителная радость. И уж лучше тогда UNIXTIME в BIGINT

спасибо за ответы и попытку меня вразумить.

жаль. я хочу хранить и выврдить всегда при любом дампе, на любом червере, при любой ситуации по дефолту UTC

set timezone = 'UTC'

set timezone = 'UTC'

блин. А дело ведь говоишь )

Ребята, есть вопрос. Если индексный файл весит 17 Гб при весе таблицы в 10 Гб — это ведь не очень ок, правда?

смотря что ты там наиндексировал

а почему файл, что \di+ показывает?

а почему файл, что \di+ показывает?

Это нужно выполнить в psql?

да

Ей ведь нужно скормить имя индекса?

Впрочем, с именем таблицы она тоже говорит, что нет подходящих отношений

ей ничего не нужно кормить

она самостоятельная

ERROR: S client not available

Все, разобрался. Нужно было явно подключится к нужной БД. Показывает, что есть 4 индекса в среднем по 4 Гб, сама таблица (по dt+) весит 9664 MB

В таблице больше 70 млн строк, кстати.

Один индекс для первичного ключа, который создается сам. Еще один уникальный составной: (col1, col2). Есть еще два отдельных для col1 и col2. Собственно, отсюда вопрос: можно ли выпилить отдельный индекс для col1, если он используется в составном индексе на первом месте?

Один индекс для первичного ключа, который создается сам. Еще один уникальный составной: (col1, col2). Есть еще два отдельных для col1 и col2. Собственно, отсюда вопрос: можно ли выпилить отдельный индекс для col1, если он используется в составном индексе на первом месте?

Да.

Только что загуглил, что да. Спасибо!

Индекс нужен для ускорения работы sql запросов?

Если грубо, то да. В индесе хранится информация, что запись, соответствующая этому условию, лежит там-то, что позволяет прочитать сначала индекс, потом конкретные записи вместо полного скана таблицы.

Привет. У меня есть таблица, в которой каждое поле я заполняю селектом. Получается куча селектов, которые по своей сути одинаковые, меняются названое столбца. Как можно оптимизировать код?

Логично предположить, что данные для одной строки, выбираемые разными селектами как-то связаны? Выбирать значения для всех полей сразу одним запросом. Или я что-то не понял

Возможно проблемы в схеме. Скорее всего столбцы должны быть строками. Но описание слишком общё. Из него ничего не понятно.

Одним запросом не могу. Там происходит удаление дубликатов, группировка и все такое. Смысл в том, что мне нужно создать изменяемый подзапрос. Чтобы в подзапросе был не селект, что-то типо функции c параметрами, по которым он будет группировать

схему данных рисовали в экселе? :)

сделай из своей кучи колонок колонку "название_колонки", положи в неё название колонки, и обращайся к ней как к данным

а потом, если нужно на это смотреть как на кросстаб, пользуйся \crosstabview

друзья помогите разобраться что я делаю неправильно: archive_command = mkdir -p ../wal_archive && test ! -f ../wal_archive/%f && cp %p ../wal_archive/%f при запуске базы должна создаться папка wal_archive и логи должны записываться туда я правильно понимаю ? test ! -f ../wal_archive/%f не понятно какую функцию выполняет эта строка

прпи запуске папка wal_archive не создается

А зачем вы создание директории в archive_command запихнули?

просто взял с шаблона конфига кластера гитлаб parameters: archive_mode: "on" wal_level: hot_standby archive_command: mkdir -p ../wal_archive && test ! -f ../wal_archive/%f && cp %p ../wal_archive/%f если создать папку рукой то нужно только test ! -f ../wal_archive/%f && cp %p ../wal_archive/%f прописать да ?

> test ! -f ../wal_archive/%f не понятно какую функцию выполняет эта строка команда выполняет проверку существования wal файла, если файл есть, то в логах появятся WARNING сообщения и файл не будет скопирован в папку wal_archive

понятно спасибо

к примеру есть таблица с двумя столбцами: a и b. как вывести самое частое значение в них одним запросом?

select mode(a), mode(b) from table;

?

точнее SELECT mode() WITHIN GROUP (ORDER BY a) AS mode_a, mode() WITHIN GROUP (ORDER BY b) AS mode_b FROM tbl;

но суть та же

o! ?

Вот это то, чего не хватало — интерфейс Постгри с автодополнением и подсветкой синтаксиса pgcli.com

точнее SELECT mode() WITHIN GROUP (ORDER BY a) AS mode_a, mode() WITHIN GROUP (ORDER BY b) AS mode_b FROM tbl;

Спасибо большое. А с группировкой будет работать? То есть если добавит id, например пользователя и вывести популярные значения для каждого пользователя ?