вопрос-то был: чем pg_dump плох

да, спасибо

Вот пусть бы хоть что то уносил , а там бы уже походу были варианты

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

^

дописывать в конец дампа analyze?

он же не переносит индексы их содержимым

добрый день всем

дописывать в конец дампа analyze?

Ну это тоже , так делается при апгрейде

Привет парни! Есть вопрос: Нужно сделать выборку из таблицы, содержащей активность пользователей, но при этом активности с типом "2" должно быть не более 5 штук на запрос. Заранее спасибо за ответы! PS: Вероятно тут надо использовать Rank но он не очень у меня подружился с group by

Скажите кроме postgrespro кто оказывает услуги по поддержке?

с PGPro не прокатывает, там версия Enterprise стоит как Оракл.

data egret например

а можно явки пароли цены услуги?)

с PGPro не прокатывает, там версия Enterprise стоит как Оракл.

так там же есть опции кроме enterprise?

https://dataegret.ru/ - для россиян

https://dataegret.com/ - для иностранцев

с PGPro не прокатывает, там версия Enterprise стоит как Оракл.

https://postgrespro.ru/services/support вообще не требует какой-то конкретной версии

https://postgrespro.ru/services/support вообще не требует какой-то конкретной версии

Спасибо, покажу начальству

https://dataegret.ru/ - для россиян

Спасибо

не знаю как с proшнкиами - не работал. а от команды data egret только очень приятные впечатления.

не знаю как с proшнкиами - не работал. а от команды data egret только очень приятные впечатления.

? учту

Привет парни! Есть вопрос: Нужно сделать выборку из таблицы, содержащей активность пользователей, но при этом активности с типом "2" должно быть не более 5 штук на запрос. Заранее спасибо за ответы! PS: Вероятно тут надо использовать Rank но он не очень у меня подружился с group by

Объясните задачу подробнее (и лучше покажите \d таблиц и тот запрос, который у вас есть)...

всем, привет, подскажите пожалуйста, в конфиге datestyle = "DMY, ISO" а отдает всё равно год-месяц-день как сделать чтобы отдавал день-месяц-год (24-04-2018)

Нужность индексов не определяется их размером, совсем. Т.е. вам нужно подробнее смотреть (например, не дублируют ли индексы друг друга, используются ли они в запросах).

Каким способом можно определить дублирующиеся индексы?

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

Каким способом можно определить дублирующиеся индексы?

https://wiki.postgresql.org/wiki/Index_Maintenance#Duplicate_indexes

Каким способом можно определить дублирующиеся индексы?

Вообще, бывают и частично перекрывающиеся, например "ON (a, b)" и "ON(a)". Тут уже можно подумать, нужен ли ON(a) (если это не constraint, естественно).

Спасибо за обратную связь

всем, привет, подскажите пожалуйста, в конфиге datestyle = "DMY, ISO" а отдает всё равно год-месяц-день как сделать чтобы отдавал день-месяц-год (24-04-2018)

А вам зачем / какая разница (я к тому, что "обычным" клиентам всё равно отдаются типизированные значения)?

А вам зачем / какая разница (я к тому, что "обычным" клиентам всё равно отдаются типизированные значения)?

чтобы я лишний раз его не конвертил туда сюда в php, кстати если ставить datestyle = "DMY, Postgres", то дата выдаётся как надо, только теперь timestamp отдаёться по умолчанию в буквенном формате с названием месяца...

ок

ну что, как там, отключили тормоза?

чтобы я лишний раз его не конвертил туда сюда в php, кстати если ставить datestyle = "DMY, Postgres", то дата выдаётся как надо, только теперь timestamp отдаёться по умолчанию в буквенном формате с названием месяца...

Т.е. у PHP нет поддержки extended (binary) protocol? Если да (и он сам не занимается форматами дат), то, наверное, придётся помучаться. :(

помоему тут не было: https://www.percona.com/blog/2018/04/24/percona-expands-services-offerings-with-postgresql-support/

Объясните задачу подробнее (и лучше покажите \d таблиц и тот запрос, который у вас есть)...

Есть таблица: id, profile, news Нужно получить: список профилей и привязанные к ним новости в виде массива. Но привязанных новостей не может быть больше 5. Если их больше 5 дублируем запись и вставляем в нее то, что осталось.

помоему тут не было: https://www.percona.com/blog/2018/04/24/percona-expands-services-offerings-with-postgresql-support/

ух! а там саппорт или писать что толковое внутрь будут? :)

Есть таблица: id, profile, news Нужно получить: список профилей и привязанные к ним новости в виде массива. Но привязанных новостей не может быть больше 5. Если их больше 5 дублируем запись и вставляем в нее то, что осталось.

И это таблица... чего? Новостей для profiles? А news какого типа? И т.д. и т.п. Вам трудно \d показать? ;)

Народ, всем привет. Интересует нету ли у postgres какой-нибудь функции для поиска наиближайшего значения для указаного?

Народ, всем привет. Интересует нету ли у postgres какой-нибудь функции для поиска наиближайшего значения для указаного?

Поиска где? В таблице, вроде "SELECT MIN(t.value) FROM t WHERE t.value > some_value ORDER BY t.value LIMIT 1;" (для следующего большего)?

Ну да, в таблице. Хммм... Да вот надо или большего или равно или меньшего, тот который ближе.

Ну да, в таблице. Хммм... Да вот надо или большего или равно или меньшего, тот который ближе.

А "ближе" уже подразумевает наличие функции расстояния, правильно? Т.е. зависит от типа: для чисел —- разность, для точек —- расстояние, для строк... ну, по выбору. ;) Вам для какого нужно?

Для чисел

Хмм, понял, что делать, подзапросом посчитать растояние и найти наименьшее?

Хмм, понял, что делать, подзапросом посчитать растояние и найти наименьшее?

https://stackoverflow.com/questions/6102824/is-there-a-postgres-closest-operator , например. По идее, это можно и в SRF попробовать завернуть...

Т.е. у PHP нет поддержки extended (binary) protocol? Если да (и он сам не занимается форматами дат), то, наверное, придётся помучаться. :(

нет, оно где-то в конфиге задаётся, datestyle = 'DMY, Postgtes' же нормальном считывает и выдает в нужном порядке день месяц год, только мне нужен другой стиль вывода даты( ISO), а вот если задать его, то он почему-то выдает дату не в том порядке в котором я ему указываю в datestyle

https://stackoverflow.com/questions/6102824/is-there-a-postgres-closest-operator , например. По идее, это можно и в SRF попробовать завернуть...

А производительнее какой вариант?

А производительнее какой вариант?

По идее, похожий на: SELECT * FROM ( (SELECT id, number FROM t WHERE number >= ? ORDER BY number LIMIT 1) AS above UNION ALL (SELECT id, number FROM t WHERE number < ? ORDER BY number DESC LIMIT 1) as below ) ORDER BY abs(?-number) LIMIT 1;

Ладно, понял, попробуем, спасио

ну что, как там, отключили тормоза?

смогу только часиков в 10-11 вечера

смогу только часиков в 10-11 вечера

Ждём, раз уж начали разбираться.

А что это за конструкция abs(?-number)?

а, фу, параметр

А что это за конструкция abs(?-number)?

Через "?" здесь обозначен параметр.

Hello everyone!

Do we have any query-optimization expert in here?

Or somebody that has worked with a GIS DB / GTFS DB?

I need to optimize a query that takes waaay to long (1 min and 18s, wtf)

explain

I have some tables with a lot of rows

one table has 11M records

and I need to do a GIS operation on that

and, based on the result, join it w/ another table of 11k-ish results

I have some tables with a lot of rows

EXPLAIN - it's the command to understand why the query runs slow

I can provide the DB schema (I wrote it on a blackboard the other day)

EXPLAIN - it's the command to understand why the query runs slow

Lol right

Already tried that

doesn't give any meaningful output tbh

doesn't give any meaningful output tbh

It always gives meaningful output :)

Query: SELECT trip.uid FROM trip, (SELECT trip_id, st.feed_id FROM (SELECT s.id, s.feed_id FROM stop as s WHERE ST_Within( ST_Transform(s.position::geometry,4326), ST_MakeEnvelope( '5.9559', '45.818', '10.4921', '47.8084', 4326) ) GROUP BY (s.id, s.feed_id)) as sq2 INNER JOIN stop_time as st ON sq2.id = st.stop_id AND sq2.feed_id = st.feed_id) as sq1 WHERE trip.trip_id = sq1.trip_id AND sq1.feed_id = trip.feed_id GROUP BY trip.uid Group (cost=25921.91..25922.30 rows=79 width=24) Group Key: trip.uid -> Sort (cost=25921.91..25922.11 rows=79 width=24) Sort Key: trip.uid -> Nested Loop (cost=10102.18..25919.42 rows=79 width=24) Join Filter: ((s.feed_id)::text = (trip.feed_id)::text) -> Nested Loop (cost=10101.63..25403.50 rows=864 width=153) -> Group (cost=10101.07..10101.15 rows=11 width=74) Group Key: s.id, s.feed_id -> Sort (cost=10101.07..10101.10 rows=11 width=74) Sort Key: s.id, s.feed_id -> Seq Scan on stop s (cost=0.00..10100.88 rows=11 width=74) Filter: (('0103000020E6100000010000000500000050FC1873D7D2174062105839B4E8464050FC1873D7D217400F0BB5A679E7474024B9FC87F4FB24400F0BB5A679E7474024B9FC87F4FB244062105839B4E8464050FC1873D7D2174062105839B4E84640'::geometry ~ st_transform(("position")::geometry, 4326)) AND _st_contains('0103000020E6100000010000000500000050FC1873D7D2174062105839B4E8464050FC1873D7D217400F0BB5A679E7474024B9FC87F4FB24400F0BB5A679E7474024B9FC87F4FB244062105839B4E8464050FC1873D7D2174062105839B4E84640'::geometry, st_transform(("position")::geometry, 4326))) -> Index Scan using "stop_time_sid-fid" on stop_time st (cost=0.56..1386.79 rows=432 width=98) Index Cond: (((stop_id)::text = (s.id)::text) AND ((feed_id)::text = (s.feed_id)::text)) -> Index Scan using trip_feed_id_idx on trip (cost=0.55..0.58 rows=1 width=113) Index Cond: (((feed_id)::text = (st.feed_id)::text) AND ((trip_id)::text = (st.trip_id)::text))

It always gives meaningful output :)

I stand corrected. It isn't useful for me, or at least I can't understand it

I mean, I can see which operations are more expensive

but I can't seem to find a way to fix the problem

This is the DB schema on a blackboard. I hope it doesn't sucks

Basically, the most expensive query happens when stop_time and trip are joined

But I need that join in order to get the routes (which are dependent on trip)

And this is the DB itself (with no data, obviously)

смогу только часиков в 10-11 вечера

? :-)

? :-)

Записал для limit, сейчас через пол часика для free, хочу убедиться что другие процессы отработали хорошо)

And this is the DB itself (with no data, obviously)

Show EXPLAIN (ANALYZE, BUFFERS). Better yet, join #postgresql or #postgis (IRC), you'll find [many] more english-speaking, competent PostgreSQL-ers there. ;)

I'll look into it, thanks!

@grinias отправил данные в личку

@grinias отправил данные в личку

все живет на RAID5 по логам iostat видно, что IO деградирует до await ~1000мс в тот момент, когда прожорливый процесс не прижат. просадка идет когда avgrq-sz (средний размер запроса в секторах) падает ниже 35 когда есть ограничения: Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sdb 4,08 0,00 32,65 172,45 4,18 3,99 81,51 18,98 94,91 20,62 108,97 4,94 101,22 sdb 7,14 0,00 23,47 137,76 3,83 2,93 85,87 19,34 125,82 15,48 144,62 5,24 84,49 sdb 8,25 0,00 26,80 114,43 4,25 2,67 100,44 10,99 71,12 8,46 85,80 6,72 94,85 когда нет ограничений: Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sdb 0,00 0,00 2,02 183,84 0,25 2,34 28,52 147,95 1028,26 786,00 1030,92 5,43 101,01 sdb 0,00 2,04 2,04 175,51 0,26 2,09 27,03 141,40 768,00 662,00 769,23 5,75 102,04 sdb 0,00 0,00 3,96 148,51 0,50 1,98 33,19 109,37 717,95 566,00 722,00 6,49 99,01 вывод: и с прижатым процессом диску уже тяжело. жить с временем ответа 80мс не очень комфортно. но тут зависит от требования заказчика. когда тормоза убирают, то устройство заваливают мелкими запросами на запись узкое место в настоящий момент - это конфигурация устройства (5+ RAID, 1ТБx8) что делать: тут 3 варианта: уйти от RAID 5 - тормоза возникают при записи, когда нужно сделать много работы по вычислению контрольной суммы. или жить с прижатым процессом (медленно, но живем) или оптимизировать прожорливый запрос (напрягаем мозг) но лучше уйти от RAID5 http://gsbelarus.com/gs/wiki/index.php/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83_%D0%BD%D0%B5%D0%BB%D1%8C%D0%B7%D1%8F_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D1%8C_RAID_5_%D0%B4%D0%BB%D1%8F_%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0_%D0%B1%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

@grinias , большое спасибо за анализ! будем думать :)

пожалуйста

все живет на RAID5 по логам iostat видно, что IO деградирует до await ~1000мс в тот момент, когда прожорливый процесс не прижат. просадка идет когда avgrq-sz (средний размер запроса в секторах) падает ниже 35 когда есть ограничения: Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sdb 4,08 0,00 32,65 172,45 4,18 3,99 81,51 18,98 94,91 20,62 108,97 4,94 101,22 sdb 7,14 0,00 23,47 137,76 3,83 2,93 85,87 19,34 125,82 15,48 144,62 5,24 84,49 sdb 8,25 0,00 26,80 114,43 4,25 2,67 100,44 10,99 71,12 8,46 85,80 6,72 94,85 когда нет ограничений: Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sdb 0,00 0,00 2,02 183,84 0,25 2,34 28,52 147,95 1028,26 786,00 1030,92 5,43 101,01 sdb 0,00 2,04 2,04 175,51 0,26 2,09 27,03 141,40 768,00 662,00 769,23 5,75 102,04 sdb 0,00 0,00 3,96 148,51 0,50 1,98 33,19 109,37 717,95 566,00 722,00 6,49 99,01 вывод: и с прижатым процессом диску уже тяжело. жить с временем ответа 80мс не очень комфортно. но тут зависит от требования заказчика. когда тормоза убирают, то устройство заваливают мелкими запросами на запись узкое место в настоящий момент - это конфигурация устройства (5+ RAID, 1ТБx8) что делать: тут 3 варианта: уйти от RAID 5 - тормоза возникают при записи, когда нужно сделать много работы по вычислению контрольной суммы. или жить с прижатым процессом (медленно, но живем) или оптимизировать прожорливый запрос (напрягаем мозг) но лучше уйти от RAID5 http://gsbelarus.com/gs/wiki/index.php/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83_%D0%BD%D0%B5%D0%BB%D1%8C%D0%B7%D1%8F_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D1%8C_RAID_5_%D0%B4%D0%BB%D1%8F_%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0_%D0%B1%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

По ссылке лишь теория, не увидел там практических хотябы тривиальных тестов показывающих преимущестов raid10 над 5. Asic контроллеров чек сумму для raid 5 вычисляют так быстро как не может их накормить даже интерфейс . Проблема raid 5 -не скорость чтения записи и пр , а работоспособность в деградированном состоянии, когда при пересчете чек сумм есть вероятность выхода из строя второго диска вследствие повышенной нагрузки на весь массив. Я такое встречал несколько раз.

@ParadoxTelegram а в каком статусе сейчас рейд, все диски живы, может вы живёте на деградировавшем рейде?

А есть каналы куда можно вакансию DBA закинуть?

А есть каналы куда можно вакансию DBA закинуть?

Можно сюда, если не реклама