Но экземпляр в системе установлен один

Ну очевидно процессы разные

Вы так больше не пугайте. А то из ваших сообщений следует, что запущен один демон на несколько баз.

Вы так больше не пугайте. А то из ваших сообщений следует, что запущен один демон на несколько баз.

С терминологией недопонимание

есть хаятушник чтобы быренько сделать постгерсс на 50к коннектов с сек и столько же записей?

Без спецовой прокси (пгбаунсер?) это вряд ли возможно, система на таком количестве процессов вероятно загнется

В этом даже смысла нет в 99% случаев

ибо 100% утилизации соединений не будет

pgbouncer самое адекватное если не требуется логики в middleware

люди, а как-то можно из поля time получить timestamp?

на стороне сервера

люди, а как-то можно из поля time получить timestamp?

язык какой?

мне бы на sql

sql, python, c++, php

мне бы на sql

понял, минуту

т.е. у меня есть поле типа time, а я хочу что=то вроде select '09:00:00'::timestamp'

формат исходного поля дай и конечного

точнее сюда напиши как должно выглядеть

т.е. у меня есть поле типа time, а я хочу что=то вроде select '09:00:00'::timestamp'

этого достаточно

не, так я тоже могу. мне чтобы без оберток

сделать функцию, которая возьмет поле как строку и потом распарсит - это не вопрос

я просто предполжил, что есть штатный способ

сделать функцию, которая возьмет поле как строку и потом распарсит - это не вопрос

я понял вопрос.

Юзал что-то типа того: `to_timestamp(_datetime, 'YYYY-MM-DD HH24:MI:SS');`

Сейчас погляжу, сработает ли это ? Она у меня в хранимке лежит :)

https://www.postgresql.org/docs/9.6/static/functions-datetime.html Вот здесь вроде описаны варианты

спасибо!! буду копать

чё копать то?

SELECT (CURRENT_DATE || ' ' || CURRENT_TIME)::timestamp;

Можно так

SELECT (CURRENT_DATE || ' ' || CURRENT_TIME)::timestamp;

ему по строке же надо. и не факт что текущий день

Ну строка нормально закастится)

И неизвестно какой часовой пояс. Недавно открыл для себя что timestamptz::date не иммутабельна

можно делать at timezone (если мне память не изменяет)

Ну я так текущее время в секундах и храню ? (date_part('epoch'::text, now()) * (1000)::double precision)

наверное это плохо :)

это ужасно

Без спецовой прокси (пгбаунсер?) это вряд ли возможно, система на таком количестве процессов вероятно загнется

у меня кассандра пишет по 70к запросов в сек, после прохода пользователя через процедуру, некоторые вещи пишутся в постгресс

просто когда-то, когда на mysql сидел, datetime толи по моему непониманию, то ли по причине ошибки в генах, то ли просто потому что это MySQL - даже если отправлять по GMT всеравно смещение времени происходит на разных серверах и вот тогда я как-то привык именно так фиксировать дату

хотя, когда не критично храню в timestamp

но такое редко. Зачастую критично, чтобы дата была верной.

в итоге пришлось таки возвращать в ::text и конвертить, потому как тут у меня свой типа NullTime (это в Go). К счастью, это справочник, так что нагрузит не слишком, я надеюсь.

@Bereznyak просвяти пожалуйста меня. Как на 100% гарантировать timestamp в gmt чтобы не было риска записать криво?

мне это важно

=> SELECT NOW() AT TIME ZONE 'gmt'; timezone ---------------------------- 2017-07-17 11:34:07.001962 (1 row)

Z в конце + парсить как timestamptz

Z в конце + парсить как timestamptz

2017-07-17 11:34:07 Z так?

нет, сорри, не отвечай, сначала доку перечитаю

Z - это iso8601 указатель на UTC

парсер timestamptz парсит таймзоны, учитывая Z

gis=# select '2017-07-17 11:34:07Z'::timestamptz; timestamptz ------------------------ 2017-07-17 14:34:07+03 (1 row)

?

gis=# select '2017-07-17 11:34:07Z'::timestamptz; timestamptz ------------------------ 2017-07-17 14:34:07+03 (1 row)

И тогда какой бы часовой пояс не был на сервере или как бы убого дамп не был развернут timestamp останется тем же?

Я понимаю что вопрос звучит глупо, но это не так :)

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

опасность таит timestamp: gis=# select '2017-07-17 11:34:07Z'::timestamp; timestamp --------------------- 2017-07-17 11:34:07 (1 row)

Ну он по идее сконвертит в локаль базы

ну, там на комбинациях начинаются интересные эффекты: gis=# select ('2017-07-17 11:34:07Z'::timestamptz)::timestamp; timestamp --------------------- 2017-07-17 14:34:07 (1 row)

отсюда растут рекомендации никогда не использовать timestamp, а всегда timestamptz :)

вот только же решил все make_date и update_date переконвертить в timestamptz А теперь вот даже в растерянности.

если очень страшно за настройки базы, то можно в запросах явно спрашивать select ('2017-07-17 11:34:07Z'::timestamptz) at time zone 'utc'; timezone --------------------- 2017-07-17 11:34:07 (1 row)

тогда вот еще вопрос чем int хуже timestamp?

нечитаебелен типа?

зависит, как ты пользуешься базой

ну во-первых, он нечитабелен человеком)

Во-вторых, его всегда надо кастить

если ты пользуешься базой не как объектно-реляционной системой управления базой данных, а как тупым хранилищем, то храни байты как тебе удобнее

ERROR: S client not available

Плюс когда-нибудь подвинут часы

сейчас вопросы полезут как пирожки!

а какая связь реляционной базы с timestamp?

это же просто тип данных

тебе важна семантика на селектах? :)

ясно

Во-вторых, его всегда надо кастить

Кого надо кастить? timestamp? Нет. Не слышали...

unixtime

а вообще спор давний

вот в постгисе в третью-четвёртую координату складывают время иногда

и у него нет никакого особенного понятия, что это время, и там просто число в юникстайме

Пространственно-временной континуум? ))

ато

а вообще спор давний

мне это нужно для понимания, не ради спора. потому что если структуру выложу в паблик это знание будут поглощать совсем начинающие (в интернете же гуглом пользуются?) и то как они запомнят, так и дальше пойдет

там даже половина функций умеет это время не замечать при рассчёте геометрического пересечения.

у меня кассандра пишет по 70к запросов в сек, после прохода пользователя через процедуру, некоторые вещи пишутся в постгресс

и дальше чего

мне это нужно для понимания, не ради спора. потому что если структуру выложу в паблик это знание будут поглощать совсем начинающие (в интернете же гуглом пользуются?) и то как они запомнят, так и дальше пойдет

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

правильно дефолт для поля make_time пишу? (NOW() AT TIME ZONE 'gmt' || 'Z')::TIMESTAMPTZ

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

Не соглашусь. Есть ещё много факторов: операторы, занимаемое место, специфичные для типов индексы.

правильно дефолт для поля make_time пишу? (NOW() AT TIME ZONE 'gmt' || 'Z')::TIMESTAMPTZ

ты хотел просто now() ?

ты хотел просто now() ?

ну в нулевом часовом поясе

часовой пояс приклеивается при выводе из timestamptz

Не соглашусь. Есть ещё много факторов: операторы, занимаемое место, специфичные для типов индексы.

операторы это тоже функции. Индексы над функциями. А место ты сам определяешь, когда кладёшь данные.

Я имел в виду, что timestamp занимает 8 байт, а дата и время в виде текста как минимум 19.

Это экономия на спичках

А бинарный тип не обязан хранить текст. Там может лежать такая же структура.

Ну ничего себе "спички". В 2.5 раза больше.

Это экономия на спичках

ага умножить на пару сотень млн и будет не спичка, а лес ))

Ну ничего себе "спички". В 2.5 раза больше.

Ну давайте вместо й писать и, тоже экономия в 2 раза!

Ну давайте вместо й писать и, тоже экономия в 2 раза!

?

бреве отдельное место занимает (не всегда)

Ну давайте вместо й писать и, тоже экономия в 2 раза!

Извините, но по-моему, вы какие-то глупости говорите.