добрый день, подскажите пожалуйста как мне извлечь значение интервала в определенных единицах(например месяца)? extract(month from interval '2 years 3 months') - result 3 а мне требуется result 27

перевести в секунды и поделить?

select extract (epoch from ((interval '2 years' + interval '3 months'))) / extract (epoch from interval '1 month');

добрый день, подскажите пожалуйста как мне извлечь значение интервала в определенных единицах(например месяца)? extract(month from interval '2 years 3 months') - result 3 а мне требуется result 27

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

27 - это что? Сильно смахивает на 42 из Автостопом по Галактике )))

27 - это 2 года * 12 месяцвев + 3

Коллеги, вопрос: Есть сервер 1 с pgsql, база: postgres, owner: postgres, schema public Хочется перенести на сервер 2 с postgres: база: name. owner: name, schema: name

как это правильно сделать?

базу собственно с содержимым)

чтобы данные были в схеме name и принадлежали owner: name

задача... она о другом, а по сути вопроса мне требуется проверить сколько единиц времени(часы/секунды) назад пользователь совершал то или иное действие и меня интересует в данном случае только результат в этих единицах, а не в человеко-понятом виде:-).

используйте unixtime

чтобы данные были в схеме name и принадлежали owner: name

почтайте доку про pg_dump/pg_restore

Прошу прощения за повторный вопрос, но всё-таки потоковая репликация между 9.5 и 9.6 невозможна?

С целью обновления с 9.5 до 9.6

точно нет

Прошу прощения за повторный вопрос, но всё-таки потоковая репликация между 9.5 и 9.6 невозможна?

Вероятно через pglogical возможно https://www.2ndquadrant.com/en/resources/pglogical/pglogical-docs/

Это будет лучше, чем через Slony?

Slony - trigger based репликация

Итоговая цель- обновление без даунтайма с 9.5 до 9.6

При обновлении с 9.4 до 9.5 через pg-upgrade даунтайм был около получаса

pglogical - логическая репликация , в каком-то смысле более встроенная в postgres

Сам не пробовал. Документация заявляет такой upgrade в качестве одной из целей использования pglogical

чем хорош pglogical? тем, что у него хотя бы bug tracker есть. потому в отличие от встроенной репликации можно оценить стабильность и масштабы использования: https://github.com/2ndQuadrant/pglogical/issues

Почему строка может быть не видна через index scan, но видна через sequential scan? https://gist.github.com/anonymous/33ab184d90e91e4c517d8fae74944db6

попробуй индекс пересоздать

это под нагрузкой? или чисто локальная база?

Добрый день коллеги Кто-нибудь пробовал ruby самописное приложение настроить подключение к базе через pgbouncer? ActionView::Template::Error (PG::UndefinedTable: ERROR: relation «table» does not exist

Это уже без нагрузки. Думаю что после пересоздания индекса эффект пропадет.

скорее всего что-то из этого: https://wiki.postgresql.org/wiki/Visibility_Map_Problems

а база как-то повреждена не была?

скорее всего что-то из этого: https://wiki.postgresql.org/wiki/Visibility_Map_Problems

Первым делом посмотрел. Это даёт обратный эффект - показывает удаленный таплы через index-only scan. Corruption of a visibility map can lead to false results from index-only scans, that is returning rows that should not be returned because they have been deleted.

а база как-то повреждена не была?

Сложный вопрос - postgres=# show data_checksums; -[ RECORD 1 ]--+---- data_checksums | off

_vm и _fsm форки соответствующего relation удалял - эффект нулевой

какая версия постгреса?

в релиз-нотсах 9.6.2: Fix a race condition that could cause indexes built with CREATE INDEX CONCURRENTLY to be corrupt (Pavan Deolasee, Tom Lane) If CREATE INDEX CONCURRENTLY was used to build an index that depends on a column not previously indexed, then rows updated by transactions that ran concurrently with the CREATE INDEX command could have received incorrect index entries. If you suspect this may have happened, the most reliable solution is to rebuild affected indexes after installing this update.

Обнаружили после update 9.5.5 => 9.5.7

этот же комментарий в ченжлоге на 9.5.6

https://www.postgresql.org/docs/9.6/static/release-9-5-6.html

ctid тапла в листьях индекса есть https://gist.github.com/anonymous/39547cd90d2f145b8da0eb1379830c88

ну, битый индекс, и с тех пор это чинили

переиндексируй и начинай ругаться, если повторится на 9.5.6+

И то могло с полгода не проявляться?

если невидимость строки никак не влияет на флоу - почему нет

pg_dump/pg_restore

Вряд ли там внутри create index concurrently

индекс на 9.5.7 создавался, или pg_upgrade c 9.5.5 перетянул?

Скореевсего pg_upgrade. Что там у yum может быть внутри?

а, туплю, между ними pg_upgrade не нужен ведь

reindex помог. А вот план теперь совсем непонятный. https://gist.github.com/anonymous/52b5e9e7081f01bf6817b7426a63e8a6 Зачем там сразу index scan и seq scan?

Postgres рассчитывает найти ещё один тапл с тем же уникальным ключем в таблице помимо тех что он нашел в индексе? И почему тогда seq scan даёт 0 rows?

analyse nicname.domains;

Просто vacuum не подразумевает analyze?

Ага, документация на 9.5 говорит что нет, не подразумевает.

analyze прошел, план не поменялся.

domains и domains_3 - это всё обычная таблица, или партиции какие?

Всем привет Меня попросили помочь потестить простые запросы для аналитики в разных системах (SQL реляционная база, Pandas, итд), выгружая и не выгружая все в память. Остальное мне не очень интересно, но вот в постгресе решил сам потестить Я нагенерил таблицу на 1 ГБ случайных чисел в постгресе вот так https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff И сделал запрос, там пример есть с EXPLAIN Возникло 2 вопроса: – Я попробовал сделать одно и то же в установленном у меня глобально 9.6.1 и девелоперском 10beta1 из мастера, в гисте есть результаты EXPLAIN. Я понимаю, что от версии к версии все должно становиться лучше, но не почти в 3 раза же?! Я не следил за ченджлистом следующего релиза, но судя по всему в 10 создаются параллельные воркеры (2 шт. у меня по дефолту), это потенциально до 2-х раз быстрее, что еще могло повлиять на производительность так сильно? – Еще я подумал, что если достаточно увеличить shared_buffers, то вся база однажды попадет в оперативку и все станет намного быстрее. Попробовал это сделать и даже использовал экстеншн pg_prewarm, но после ~10 запросов shared hit так и остался низким, при этом процесс postgres как отъедал мало оперативки, так и продолжил. Что я сделал не так и как вообще можно добиться полного попадания таблицы/базы в память, если размеры позволяют?

domains и domains_3 - это всё обычная таблица, или партиции какие?

domains_3 партиция domains

Всем привет Меня попросили помочь потестить простые запросы для аналитики в разных системах (SQL реляционная база, Pandas, итд), выгружая и не выгружая все в память. Остальное мне не очень интересно, но вот в постгресе решил сам потестить Я нагенерил таблицу на 1 ГБ случайных чисел в постгресе вот так https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff И сделал запрос, там пример есть с EXPLAIN Возникло 2 вопроса: – Я попробовал сделать одно и то же в установленном у меня глобально 9.6.1 и девелоперском 10beta1 из мастера, в гисте есть результаты EXPLAIN. Я понимаю, что от версии к версии все должно становиться лучше, но не почти в 3 раза же?! Я не следил за ченджлистом следующего релиза, но судя по всему в 10 создаются параллельные воркеры (2 шт. у меня по дефолту), это потенциально до 2-х раз быстрее, что еще могло повлиять на производительность так сильно? – Еще я подумал, что если достаточно увеличить shared_buffers, то вся база однажды попадет в оперативку и все станет намного быстрее. Попробовал это сделать и даже использовал экстеншн pg_prewarm, но после ~10 запросов shared hit так и остался низким, при этом процесс postgres как отъедал мало оперативки, так и продолжил. Что я сделал не так и как вообще можно добиться полного попадания таблицы/базы в память, если размеры позволяют?

2 воркера - это 2 воркера + родитель, т.е. 3 воркера

2 воркера - это 2 воркера + родитель, т.е. 3 воркера

Хм, если так, то с этим все более менее понятно: запрос хорошо параллелится и как раз в 2.5 раза быстрее стало, неплохо. Спасибо за ответ

Хм, если так, то с этим все более менее понятно: запрос хорошо параллелится и как раз в 2.5 раза быстрее стало, неплохо. Спасибо за ответ

А если посмотреть вывод iotop -a ? Видно что три процесса параллельно читают?

там же в плане видно, 6666667 строк на воркер - это 20000000 на три

Всем привет Меня попросили помочь потестить простые запросы для аналитики в разных системах (SQL реляционная база, Pandas, итд), выгружая и не выгружая все в память. Остальное мне не очень интересно, но вот в постгресе решил сам потестить Я нагенерил таблицу на 1 ГБ случайных чисел в постгресе вот так https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff И сделал запрос, там пример есть с EXPLAIN Возникло 2 вопроса: – Я попробовал сделать одно и то же в установленном у меня глобально 9.6.1 и девелоперском 10beta1 из мастера, в гисте есть результаты EXPLAIN. Я понимаю, что от версии к версии все должно становиться лучше, но не почти в 3 раза же?! Я не следил за ченджлистом следующего релиза, но судя по всему в 10 создаются параллельные воркеры (2 шт. у меня по дефолту), это потенциально до 2-х раз быстрее, что еще могло повлиять на производительность так сильно? – Еще я подумал, что если достаточно увеличить shared_buffers, то вся база однажды попадет в оперативку и все станет намного быстрее. Попробовал это сделать и даже использовал экстеншн pg_prewarm, но после ~10 запросов shared hit так и остался низким, при этом процесс postgres как отъедал мало оперативки, так и продолжил. Что я сделал не так и как вообще можно добиться полного попадания таблицы/базы в память, если размеры позволяют?

а про второе - сколько shared_buffers?

http://pgtune.leopard.in.ua/ натравливали? :)

а про второе - сколько shared_buffers?

Поставил с запасом 4 ГБ. Попробовал сейчас pgtune, тоже 4 советует :) Да, действительно, по строкам совпадает. Я все на время смотрел, пропустил

ERROR: S client not available

а по скоростям - обычно быстрее или в 10, или в 100 раз :)

так что да, 2.5 - необычно мало

Имея всего 2 (+1) воркера было бы странно получить ускорение сразу в 10 раз :)

ребят Добрый день всем, в pgadmin 3 ничайно удалил таблицы, как можно вернуть кто знает

Undo нету так-то. pg_dump нужен был перед удалением ))

то есть никак

?

да, никак. а ведь он три раза небось спросил..?

один :)

нет 1)

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

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

да блин там другая ситуация была, я хотел кое что другое удалить, а он взял и всю таблицу

да ладно, не расстраивайся. у меня есть опыт пострашнее - удалил весь кластер бд заодно с хомой юзера. теперь пользуясь mc под рутом я ОЧЕНЬ осторожен. особенно под утро бессонной ночи ?

да ладно, не расстраивайся. у меня есть опыт пострашнее - удалил весь кластер бд заодно с хомой юзера. теперь пользуясь mc под рутом я ОЧЕНЬ осторожен. особенно под утро бессонной ночи ?

ничене понял но звучит реально страшно)) да я уже заново делаю

5 дней псу под хвост, ага

господа, кстати про отмены. видимо неправильно составил апдейт и за ночь выжралось 100% диска под базой. как пожать теперь подскажите пожалуйста?

620К записей придется апдейтить как-то хитрее... однако мне повезло, отмена выполнения запроса откатиро транзакцию похоже и место освободилось на диске

всем хорошего дня!

ребята, для имени фамилии там character varying использовать нормльно? или есть немного лучше типы данных

text

text

о спасибо

620К записей придется апдейтить как-то хитрее... однако мне повезло, отмена выполнения запроса откатиро транзакцию похоже и место освободилось на диске

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

покажи запрос. 620 000 записей апдейтятся за минуты.

и вообще, где план? :)

пока могу только сказать что count по тому же условию 10 мин тупит

план покажи

вдруг у тебя там seq scan по таблице, потому что ты пересекаешь с россией, ббокс которой накрывает половину мира из-за захлёста за 180 градусов

о-па, про 180 конечно забыл )

план покажи

с телефона 4" придётся (

но не секскан точно. ладно-ладно, вернусь с планом )