@pgsql

Страница 788 из 1062
Stas
02.05.2018
22:21:48
не понял что ты тут протестишь, скорость импорта что ли ну то есть как ты сходишь в транзакции в другую ноду
сделать импорт, потом обычную pgbench-транзакцию. В такой транзакции visibility можно проверять только по CSN, постгресовый снапшот не поможет. Скорость в итоге будет меньше

Evgeniy
02.05.2018
22:23:18
сделать импорт, потом обычную pgbench-транзакцию. В такой транзакции visibility можно проверять только по CSN, постгресовый снапшот не поможет. Скорость в итоге будет меньше
ну что бы сделать импорт, надо сперва в каком-то пгбенче сделать экспорт и как-то между ними передавать айдишники цсн

тут проще уж ycsb патчить

Google
Evgeniy
02.05.2018
22:24:05
там и профилей нагрузки больше

Evgeniy
02.05.2018
22:25:01
тогда у тебя нет дистрибутед транзакции

и все xid тоже локальные

Stas
02.05.2018
22:25:32
но нода-то об этом не знает)

xid всегда локальные

Evgeniy
02.05.2018
22:25:44
ну так это будет тест скорости импорта снапшота

Stas
02.05.2018
22:26:23
ноуп, алгоритм проверки видимости другой в этом случае

и вот его хочется потестить

Evgeniy
02.05.2018
22:27:00
ну видимость будет проверяться если индабт

а индабт как будет, если нет препаре

Stas
02.05.2018
22:27:39
ну видимость будет проверяться если индабт
это с той стороны которая экспортит

а с той которая импортит — всегда по CSN проверять

Google
Evgeniy
02.05.2018
22:28:16
2) If we are in backend that imported global snapshot, then only CSN-based visibility can be used. But that happens only for global transactions. вижу

так, а csn-based это просто время спросить?

тут как обычно взвоют за гет_каррент_тайм_миллис

Stas
02.05.2018
22:28:54
вся эта возня с InDoubt это оптимизация, что постгрес где много локальных и мало глобальных меньше тормозил

но могут и взвыть)

но в теории это решаемый вопрос

Evgeniy
02.05.2018
22:30:47
а как для CSN-based visibility происходит маппинг xid на csn в этой системе?

прихраниваем время коммита всех?

Stas
02.05.2018
22:31:21
так, а csn-based это просто время спросить?
скорее основная засада в том что надо будет в мапу лазить и смотреть какой csn у данного xid

Evgeniy
02.05.2018
22:32:09
то есть тут есть кусочек патча про локал цсн?

Stas
02.05.2018
22:32:11
эта штука больше всего и тормозит в CSN патче, который про обычные транзакции

Evgeniy
02.05.2018
22:32:45
ага, первый патч

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

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

а если глобальный патч по csn закоммитят, то мапка не нужна потому что csn будет в хипе с тюплей лежать да?

ну типа надежды есть

или у csn патча те же проблемы?

Google
Mikhail
03.05.2018
08:23:50
Evgeniy
03.05.2018
08:24:23
а чем отстреливали? или в самой транзакции считали?

Mikhail
03.05.2018
08:34:39
а чем отстреливали? или в самой транзакции считали?
В самой транзакции — и кидали еррор. Защита от долгих локов. Для батчевых операций при этом был свой фреймворк

Evgeniy
03.05.2018
08:35:44
ну ты тут защищался не от долгих а от большого количества то есть неявно на айдл сешон таймаут перешли?

Stas
03.05.2018
08:46:27
а если глобальный патч по csn закоммитят, то мапка не нужна потому что csn будет в хипе с тюплей лежать да?
а там в основном патче тоже мапка. Была еще версия, где на проставление хинтбитов еще заменялась пара xmin:xmax на csn (он 8 байт), но я не знаю какая судьба у этого патча

Mikhail
03.05.2018
08:53:40
кто-нибудь пользует citus?

Dmitry
03.05.2018
09:23:02
2018-05-03 09:13:13 UTC [28652]: [56-1] db=,app=[unknown],client=10.10.10.101 ERROR: spiexceptions.OutOfMemory: out of memory 2018-05-03 09:13:13 UTC [28652]: [57-1] db=,app=[unknown],client=10.10.10.101 DETAIL: Failed on request of size 160621405.

как бороться? на машине память есть

Yaroslav
03.05.2018
09:24:24
как бороться? на машине память есть
Какая версия PostgreSQL? Когда именно происходит?

Dmitry
03.05.2018
09:25:17
9.6.6 когда 100-метровый объект зачитывается в память через plpython

через недельку :)

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

Mikhail
03.05.2018
09:31:44
доки на психоПГ посмотреть и shmax shmin проверить

Dmitry
03.05.2018
09:32:38
shmax/shmin же вроде в прошлом.

тут именно что-то фрагментируется

Mikhail
03.05.2018
09:32:57
мм... тогда сорян

про психопг тож погорячился

не разглядел сперва приставку PL :)

Yaroslav
03.05.2018
09:34:14
9.6.6 когда 100-метровый объект зачитывается в память через plpython
Похоже на memory leak (или фрагментацию). Ну а пробовали смотреть, сколько памяти использует этот backend? Может, в python тоже есть какие-то средства для отладки потребления памяти?

Dmitry
03.05.2018
09:34:21
тут косяк именно на plpython

Google
Dmitry
03.05.2018
09:34:31
он же создает контекст и никогда его не удаляет

нету никаких ручек для его управления?

короче в plpython использует объект который в конце не удаляется (= None или как-то так)

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

Who is?
03.05.2018
10:20:52
data = db.query("SELECT CASE WHEN age(now(), update) > '00:25:00' THEN 0 ELSE 1 END AS state") FROM public.ins_ampp_route limit 1") Оч помощь нужна, Что тут может быть неверно?))) кидает ошибку на FORM

Who is?
03.05.2018
10:22:31
Спс)

а куда ковычку добавить?)) все перепробывал вылетают различные ошибки синтаксиса

Александр
03.05.2018
10:24:59
data = db.query('SELECT CASE WHEN age(now(), update) > ''00:25:00'' THEN 0 ELSE 1 END AS state FROM public.ins_ampp_route limit 1')

Yaroslav
03.05.2018
10:33:32
Литералы —- в одинарных кавычках, идентификаторы —- в двойных. Со скобками сами разберётесь, я думаю. ;)

Who is?
03.05.2018
10:33:55
Ок, спс

Глеб
03.05.2018
11:36:47
Господа знатоки, помогите, пожалуйста или хотя-бы укажите куда копать. Есть такой запрос: explain ( analyse, timing, buffers ) SELECT t.id FROM timelines as t JOIN locations as l ON l.id=t.location_id WHERE st_dwithin( st_transform(l.point, 2249), st_transform(st_setsrid(st_point(33.3, 22.2), 4326), 2249), t.radius );

Вывод такой: Merge Join (cost=1591.48..11035.91 rows=1 width=4) (actual time=141.077..141.077 rows=0 loops=1) Merge Cond: (t.location_id = l.id) Join Filter: ((st_transform(l.point, 2249) && st_expand(''0101000020C9080000820454358A0D7C411E638AF3C6126E41''::geometry, (t.radius)::double precision)) AND (''0101000020C9080000820454358A0D7C411E638AF3C6126E41''::geometry && st_expand(st_transform(l.point, 2249), (t.radius)::double precision)) AND _st_dwithin(st_transform(l.point, 2249), ''0101000020C9080000820454358A0D7C411E638AF3C6126E41''::geometry, (t.radius)::double precision)) Rows Removed by Join Filter: 3349 Buffers: shared hit=169111 -> Index Scan using idx_timeline_location on timelines t (cost=0.28..247.92 rows=3349 width=12) (actual time=0.008..2.297 rows=3349 loops=1) Buffers: shared hit=2090 -> Index Scan using locations_pkey on locations l (cost=0.42..9300.60 rows=210706 width=36) (actual time=0.006..94.722 rows=210600 loops=1) Buffers: shared hit=167015 Planning time: 0.513 ms Execution time: 141.107 ms

блин... фейл

https://pastebin.com/VZz5ui8j

Вот

Darafei
03.05.2018
11:38:01
а проблема какая?

Глеб
03.05.2018
11:38:02
Проблема - не используется индекс по location.point

Google
Глеб
03.05.2018
11:38:37
Но если вместо t.radius использовать константу - то всё работает замечательно

https://pastebin.com/npZ788iq

Индекс - create index idx_location_point on locations using gist (st_transform(point, 2249));

Dmitrii
03.05.2018
11:40:24
А посоветуйте пожалуйста. Надо в таблице хранить продажи,у каждой продажи есть commission split для нас и для партнера. Может так случиться, что в один день это значение поменяется, и вся статистика порушится. Значит к каждой продаже надо хранить старое значение commission split. Как бы вы хранили? Прямо значением в запили или выносили и делали fk на таблицу комиссий?

Darafei
03.05.2018
11:40:41
да, он не может в таком виде инлайнить
https://stackoverflow.com/questions/40919364/st-dwithin-does-not-use-index-with-non-literal-argument/49943387#49943387

Глеб
03.05.2018
11:41:18
Можно с этим что-то сделать?

Darafei
03.05.2018
11:41:50
Глеб
03.05.2018
11:42:50
Спасибо, я как раз от такой реализации и побежал искать способы поочевиднее.

Darafei
03.05.2018
11:43:34
нет в постгресе оператора, в который можно передать три операнда :(

Глеб
03.05.2018
11:44:35
Тут всё осложняется тем прискорбным фактом, что точка и радиус лежат в разных таблицах

Darafei
03.05.2018
11:44:40
а индексами пользуются только те операторы, у которых из двух один аргумент константен

Глеб
03.05.2018
11:44:57
Видимо, придется переделывать сие ясделие.

Darafei
03.05.2018
11:45:21
ну, можно аккуратно субселектами и ручным инлайнингом это порешать

если ты, например, знаешь верхнюю границу радиуса, можно что-то сделать

или возможно тебе на самом деле нужен knn

Глеб
03.05.2018
11:48:33
Пожалуй, пока есть время, я отстрелю отдельную таблицу locations и почитаю про knn, возможно, это то что нужно. Спасибо.

Глеб
03.05.2018
11:58:16
а индексами пользуются только те операторы, у которых из двух один аргумент константен
Если интересно - перенес столбец с координатами в таблицу с радиусами и проиндексировал create index idx_timeline_location on timelines using gist(st_expand(st_transform(location, 2249), radius));. st_dwithin косвенно подцепил индекс.

Страница 788 из 1062