вы из консоли неправильно к базе подключаетесь, надо с указанием юзера, а если для него нет одноимённой бд, то и базу тоже как-то так: psql -U postgres -d postgres

pg_ctl вам не нужен, так как есть возможности запуска повыше уровнем: вебконсоль, либо bat-скрипт, который лежит в C:\PostgreSQL

pg_ctl вам не нужен, так как есть возможности запуска повыше уровнем: вебконсоль, либо bat-скрипт, который лежит в C:\PostgreSQL

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

чтобы убрать предупреждение надо перед запуском psql в консоли выполнить chcp 1251

pg_ctl вам не нужен, так как есть возможности запуска повыше уровнем: вебконсоль, либо bat-скрипт, который лежит в C:\PostgreSQL

вся вкурил. под линуксом я тоже запускал от имени: sudo -u postgres psql

ок, рад помочь

select * медленнее чем select ab,c,?

смотря из каких джоинов колонки надо вытягивать и сможет ли это соптимизировать планировщик

но иногда да, и в целом лучше тащить минимум

select * медленнее чем select ab,c,?

Выбор только нужных столбцов может помочь оптимизатору использовать такие штуки, как index only scan и semi-join, например.

Выбор только нужных столбцов может помочь оптимизатору использовать такие штуки, как index only scan и semi-join, например.

нет, я в том смысле, что a,b,c - это все колонки, которые перечисленны. смысл тот же, что у *, но говорят что * использовать не кошерно

в смысле не какие-то отдельные колонки, а вообще все, просто всместо * я их перечисляю в запросе

нет, я в том смысле, что a,b,c - это все колонки, которые перечисленны. смысл тот же, что у *, но говорят что * использовать не кошерно

Не кошерно. Только для запросов в каком-нибудь пгадмин, тогда да, сгодится.

Добавите потом столбец и запрос в хранимке сломается.

ну вот, некошегно. все говорят некошегно. но почему?

select * from table - это БОЛЬ при изменении структуры БД и кода проекта

select * from table1 union all select * from table2 при изменении схемы любой из таблиц поедет

В консоли select * - вполне себе. В коде проекта не надо так делать. Были у меня преценденты.

insert into () select * from тоже редкая боль когда добавляется столбец в таблицу

* на продакшене это зло

и не дай боже количество колонок совпадёт, а типы будут совместимы - это ещё и не заметите

вот теперь понятно. спасибо)

@Komzpa у меня были проблемы при отработке процедуры отката на предыдущий релиз.

и не дай боже количество колонок совпадёт, а типы будут совместимы - это ещё и не заметите

Уууххх! Вот на такие приключения нарываться не приходилось - Бог миловал. Но зарубку на память надо сделать.

у меня с csv формата lon, lat, heading, accuracy, ... - сплошь и рядом :)

Есть таблица (id serial primary key, ctime timestamp default current_timestamp, rate numeric) Нужно найти среднee значение rate за час с момента последнего ctime. Есть ли вариант лучше? select avg(rate) from table where ctime + interval '1 hour' > ( select ctime from table order by id desc limit 1 )

Есть таблица (id serial primary key, ctime timestamp default current_timestamp, rate numeric) Нужно найти среднee значение rate за час с момента последнего ctime. Есть ли вариант лучше? select avg(rate) from table where ctime + interval '1 hour' > ( select ctime from table order by id desc limit 1 )

Начните отсюда https://www.postgresql.org/docs/current/static/tutorial-window.html

Да вот что-то c оконными функциями лучше не придумывается

А, нужна одна строчка!

Поделитесь?

Возможно select max(ctime) будет лучше чем order by limit 1

И если есть индекс по ctime лучше + interval '1hour' перенести вправо как - interval '1hour'

нет, индекса нет по ctime. есть по id.

> Нужно найти среднee значение rate за час с момента последнего ctime. Непонятное условие. Если у вас ctime последний, он же максимальный, то условие "строго блоьше" where ctime + interval '1 hour' > ( select ctime from table order by id desc limit 1 ) должно дать пустое множество. Может всё же нужны записи за час до макс. ctime?

ctime последний = максимальный, да. нужны записи за час до макс. ctime, да “должно дать пустое множество” - почему?

А не. Всё ок. Я бы написал ctime > max(ctime) -1 . Тоже самое.

Индекс по ctime всё же не помешал бы

У меня это c переменной в процедуре. var.start := (select ctime - interval '1 hour' from table order by id desc limit 1); И второй селект c where ctime > start

А такой вариант: with (select max(ctime) max_ct from table) ct select avg(rate) from table where ctime between ct.max_ct and ct.max_ct - interval '1 hour'

кодировка в консоли и внутреняя не совпадают

\l покажи

в настройках консоли поколупайся

кажется примерно так меняется: https://www.postgresql.org/message-id/540740644E9D4387ADE20C63A12BB726%40HIRO57887DE653

кажется примерно так меняется: https://www.postgresql.org/message-id/540740644E9D4387ADE20C63A12BB726%40HIRO57887DE653

спассибо, set LANG=EN сработало

о, тоже вариант

я создал роль rt через GUI, зашел в psql там через \password rt установил парль на этого пользователя. А как мне теперь проверить этот пароль?

psql -U rt -d postgres

не факт что он в pg_hba появился

psql -U rt -d postgres

вошел не спрашивая пароля

вошел не спрашивая пароля

Значит локальных пользователей он пускает без пароля. Давайте попробуем через сеть psql -U rt -d postgres -h localhost

Но, как сказали выше, надо посмотреть что написано в pg_hba.conf и там разрешить доступ нужных пользователей к нужным базам с нужных адресов.

Значит локальных пользователей он пускает без пароля. Давайте попробуем через сеть psql -U rt -d postgres -h localhost

тоже самое

блять. Это какой-то звиздец

прописал все в конфигах рейлс

почему он от моего имени тыкается

надо смотреть, там есть хитрость в виде ident

А в pg_hba.conf что? Кроме коментов :)

надо смотреть, там есть хитрость в виде ident

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

pg_hba.conf - поменял вс на на passwrod заработало

теперь при psql -U rt -d postgres спрашивает пароль

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

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

тут разборался

Ребята, есть таблица с полем my_table(id bigserial, expiration_time TIMESTAMP). Делаю запрос: SELECT * FROM my_table WHERE expiration_time > CURRENT_TIMESTAMP; У всех сущностей значение поля expiration_time идентичное. Иногда порядок записей по id меняется, т.е. обычно это% 1, 2, 3, а порой: 1, 3, 2 например. Это обусловлено тем, что PostgreSQL не дает гарантий, в каком порядке вернутся записи?

да

Для гарантированного порядка надо использовать ORDER BY

Ребята, есть таблица с полем my_table(id bigserial, expiration_time TIMESTAMP). Делаю запрос: SELECT * FROM my_table WHERE expiration_time > CURRENT_TIMESTAMP; У всех сущностей значение поля expiration_time идентичное. Иногда порядок записей по id меняется, т.е. обычно это% 1, 2, 3, а порой: 1, 3, 2 например. Это обусловлено тем, что PostgreSQL не дает гарантий, в каком порядке вернутся записи?

Хорошо, что вы хоть собственными глазами увидели это. А то есть такие, которые не верят ))

Сделал даже забавнее: изменил expiration_time согласно росту id, порядок вовсе стал почти случайным: 2, 3, 1

Ладно, спасибо всем. Буду знать ?

Причем если обновить какую-то строку (там есть и другие неважные поля, в примере я опустил их) -- она выскакивает вверх ?

Причем если обновить какую-то строку (там есть и другие неважные поля, в примере я опустил их) -- она выскакивает вверх ?

хых, не я один это заметил...

потому что предыдущая стирается а новая на диске в другом месте лежит

Не стирается, а помечается, как удалённая.

ну это уже не важно. вакуум ее подчистит в итоге

главное что новая в другом месте

Да, тогда все вполне логично. Насколько я читал, UPDATE на самом деле является INSERT.

там хитрее

Если не ошибаюсь, кстати, это вы скидывали статью на Хабре, где об этом рассказывали.

Если мне память не изменяет, тонкости описаны вот здеся: https://postgrespro.ru/education/courses/DBA2

когда таблица длиннее страницы (первая цифра в ctid), то постгрес постарается впихнуть апдейтнутую запись всё ещё в ту же страницу, и вставка будет "в середину"

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

Здеся, однако 3. Страницы и версии строк

так что это наблюдение ценное, но в общем случае непредсказуемое

Если мне память не изменяет, тонкости описаны вот здеся: https://postgrespro.ru/education/courses/DBA2

Огромное спасибо!

Кстати, тут вот сегодня несчастный разработчик страдал. Ему совсем не помешает ознакомиться с базовым курсом: https://postgrespro.ru/education/courses/DBA1

https://m.habrahabr.ru/company/postgrespro/blog/337502/

Если подходить с точки зрения теоремы CAP, то stolon про консистентность, patroni про доступность.

Now wait a sec! Не могу же я пройти мимо такой жирной темы. С точки зрения CAP они не являются ни CP, ни AP-системами. C подразумевает, что при записи W1 последующее чтение R2 всегда будет видеть значение W1 или более позднее, т.е. самое свежее; возврат ошибки или устаревшего значения запрещены. Patroni прямо говорит, что даже при синхронном коммите двое могут закоммититься, после чего мастером будет выбран незакоммитившийся, Stolon же в теории мог бы добиться нужного результата, если бы с помощью бэкенда хранения прогонял бы по одному запросу за раз (т.е. установил бы очень диктаторский SERIALIZABLE). Но Stolon тупо проверяет состояние раз в пять секунд, что не помешает закоммитить W1 на нескольких (но не всех) нодах, после чего потерять их, выбрать мастером ноду без W1 и (sic!) не заметить таким образом коммита. A же говорит о том, что запрос рано или поздно закончится и не будет висеть бесконечно в ожидании восстановления сети (кворума) - возможно, ценой возврата неактуального значения (возврат ошибки опять запрещен - P подразумевает, что система работает в условиях разделения сети). Т.к. оба предоставляют просто TCP-прокси к конкретному узлу, при его недоступности никакого результата не будет получено вообще - а значит это и не AP-системы тоже.