Коллеги, а кто помнит, онлайн тюнер, который не pgtuner? Блин, не могу вспомнить.

http://pgtune.leopard.in.ua/ ?

А вот этот видели: http://pgconfigurator.cybertec.at/

Коллеги, а кто помнит, онлайн тюнер, который не pgtuner? Блин, не могу вспомнить.

Pgconfig

Товарищи, поймал интересную штуку: SELECT CAST('2147483647 milliseconds' AS INTERVAL) отдает 596:31:23.647, но SELECT CAST('2147483648 milliseconds' AS INTERVAL) уже ругается ERROR: interval field value out of range: "2147483648 milliseconds" LINE 1: SELECT CAST('2147483648 milliseconds' AS INTERVAL)

пользуйся SELECT CAST('2147483.648 seconds' AS INTERVAL) ;

Да, спасибо. Просто не ожидал, что для хранения значения внутри используется int, тем более signed

этого полно внутри постгреса

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

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

разморозили чтоли %)?

разморозили чтоли %)?

котик, ты чего сказать-то хотел?

Товарищи, поймал интересную штуку: SELECT CAST('2147483647 milliseconds' AS INTERVAL) отдает 596:31:23.647, но SELECT CAST('2147483648 milliseconds' AS INTERVAL) уже ругается ERROR: interval field value out of range: "2147483648 milliseconds" LINE 1: SELECT CAST('2147483648 milliseconds' AS INTERVAL)

нуу.. хотя бы ругается :)

Да, это радует, конечно ?

Народ, а вот такой дурацкий вопрос: допустимо ли в процедуре pl/pgsql софрмировать массив данных, а потом залить его в какую-нибудь таблицу по через COPY? Кто-нибудь такое вытворял?

Народ, а вот такой дурацкий вопрос: допустимо ли в процедуре pl/pgsql софрмировать массив данных, а потом залить его в какую-нибудь таблицу по через COPY? Кто-нибудь такое вытворял?

Unnest, не?

Товарищи, поймал интересную штуку: SELECT CAST('2147483647 milliseconds' AS INTERVAL) отдает 596:31:23.647, но SELECT CAST('2147483648 milliseconds' AS INTERVAL) уже ругается ERROR: interval field value out of range: "2147483648 milliseconds" LINE 1: SELECT CAST('2147483648 milliseconds' AS INTERVAL)

Вообще это целенаправленное действие - проверка на integer диапазон, несмотря на то что внутри число парсится в long. Другое дело, в доке указано, что только месяцы и дни приводятся к integer, а секунды распадаются на целое и дробное. По-хорошему, CAST('2147483648 milliseconds' AS INTERVAL) должен свестись к CAST('2147483 seconds 648 milliseconds' AS INTERVAL) который работает, поэтому имхо это баг. Что касается signed, то каждая компонента интервала может иметь знак: '1 hour -1 minute’ есть 00:59:00

Вообще это целенаправленное действие - проверка на integer диапазон, несмотря на то что внутри число парсится в long. Другое дело, в доке указано, что только месяцы и дни приводятся к integer, а секунды распадаются на целое и дробное. По-хорошему, CAST('2147483648 milliseconds' AS INTERVAL) должен свестись к CAST('2147483 seconds 648 milliseconds' AS INTERVAL) который работает, поэтому имхо это баг. Что касается signed, то каждая компонента интервала может иметь знак: '1 hour -1 minute’ есть 00:59:00

Это все догадки, в реализации то что?

Это все догадки, в реализации то что?

Догадки основаны на реализации) Каждое целое число в строке проверяется на вхождение в integer диапазон

Догадки основаны на реализации) Каждое целое число в строке проверяется на вхождение в integer диапазон

Реализация напоминает ситуацию с to_timestamp

Возможно)

Правда там сразу в доке было написано что если на входе булшит то и на выходе тоже. Зато честно %)

Благо дело ситуация к исправлению движется.

А кто-нибудь может сказать, что подразумевается под data truncation здесь: Exception raised for important warnings like data truncations while inserting, etc http://initd.org/psycopg/docs/module.html#psycopg2.Warning

А кто-нибудь может сказать, что подразумевается под data truncation здесь: Exception raised for important warnings like data truncations while inserting, etc http://initd.org/psycopg/docs/module.html#psycopg2.Warning

Может быть, речь о "ERROR: value too long for type ..." (но это просто догадка)?

Вообще это целенаправленное действие - проверка на integer диапазон, несмотря на то что внутри число парсится в long. Другое дело, в доке указано, что только месяцы и дни приводятся к integer, а секунды распадаются на целое и дробное. По-хорошему, CAST('2147483648 milliseconds' AS INTERVAL) должен свестись к CAST('2147483 seconds 648 milliseconds' AS INTERVAL) который работает, поэтому имхо это баг. Что касается signed, то каждая компонента интервала может иметь знак: '1 hour -1 minute’ есть 00:59:00

Спасибо за столь подробный ответ, очень познавательно. Я самостоятельно попытался покопаться в исходниках и, «почитав по диагонали», пока нашёл только typedef, не добравшись до парсинга. :)

Ребята, всем привет

кто-нибудь сталкивался

с отсутствием одного ID

id —— 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

eas=# select id from n_objects where id =37 ; id —— (0 строк)

Что за?

Что за?

Тип поля - число?

да

Что за?

А если "set enable_indexscan = off;" и SELECT * FROM n_objects WHERE id =37 ;

eas=# SELECT * FROM n_objects WHERE id =37; id | id_region | id_channel | title | address | lat | lon | deleted | id_level | id_control_object | id_icon_file | state | state_time | state_message | priority | radius | details | local_lat | local_lon —--+-----------+------------+-------+---------+-----+-----+---------+----------+-------------------+--------------+-------+------------+---------------+----------+--------+---------+-----------+---------— (0 строк)

А план какой?

то есть? Строение таблицы

??

то есть? Строение таблицы

Нет, EXPLAIN. Вы "set enable_indexscan = off;" выполнили?

EXPLAIN ANALYZE SELECT * FROM n_objects WHERE id =37 ;

Перед запросом добавьте EXPLAIN ANALYZE

eas=# EXPLAIN ANALYZE SELECT * FROM n_objects WHERE id =37 ; QUERY PLAN —------------------------------------------------------------------------------------------------------------------------------------- Index Scan using notification_objects_pkey on n_objects (cost=0.14..8.16 rows=1 width=219) (actual time=0.007..0.007 rows=0 loops=1) Index Cond: (id = 37) Planning time: 0.197 ms Execution time: 0.051 ms (4 строки)

Не отключили индекс скан.

Пересоздайте индекс, короче.

как?

подскажите, плиз

В вашем случае как-то так: alter table n_objects drop constraint notification_objects_pkey; alter table n_objects add primary key (id);

спасибо

@pensnarik а REINDEX не поможет?

подняли в osm вопрос о синхронности репликации https://lists.openstreetmap.org/pipermail/dev/2018-February/030134.html https://lists.openstreetmap.org/pipermail/dev/2018-February/030135.html

Можно и REINDEX

Пересоздайте индекс, короче.

Вы что!? Это битая база.

спасибо

Найдите причину, восстановите из backup.

Какая битая база?

А, в том смысле, что индекс битый. Вообще странно, что индекс на такой маленькой таблице оказался битым.

Кстати, какая вас версия?

psql (9.4.5)

Какая битая база?

Обычная. Почему Вы думаете, что проблема только с индексом? Вообще, что-то перениндексировать в такой ситуации —- это неправильный/вредный совет, в принципе.

Самой базы. select version();

Обычная. Почему Вы думаете, что проблема только с индексом? Вообще, что-то перениндексировать в такой ситуации —- это неправильный/вредный совет, в принципе.

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

------------------------------------------------------------------------------------------------------------------------ PostgreSQL 9.4.5 on x86_64-suse-linux-gnu, compiled by gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973], 64-bit (1 строка)

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

Кстати, да, тут я поспешил.

------------------------------------------------------------------------------------------------------------------------ PostgreSQL 9.4.5 on x86_64-suse-linux-gnu, compiled by gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973], 64-bit (1 строка)

Вы убедились, что дело было в индексе?

спасибо, за советы посмотрю и напишу