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

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

чтобы не скрывало проблемы за фдв

идея в этом, да

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

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

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

там и профилей нагрузки больше

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

так это просто время же =) now - 42ms вполне себе валидный снапшот

тогда у тебя нет дистрибутед транзакции

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

но нода-то об этом не знает)

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

ну так это будет тест скорости импорта снапшота

ноуп, алгоритм проверки видимости другой в этом случае

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

ну видимость будет проверяться если индабт

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

ну видимость будет проверяться если индабт

это с той стороны которая экспортит

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

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 это просто время спросить?

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

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

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

ну на линуксах VDSO быстрый

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

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

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

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

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

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

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

именно

то есть тут есть кусочек патча про локал цсн?

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

то есть тут есть кусочек патча про локал цсн?

ага, вот эта мапа

ага, первый патч

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

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

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

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

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

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

Мы такое в авито делали на логическом уровне — транзакция не может наменять более N однотипных объектов

а чем отстреливали? или в самой транзакции считали?

а чем отстреливали? или в самой транзакции считали?

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

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

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

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

кто-нибудь пользует citus?

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.

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

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

Какая версия PostgreSQL? Когда именно происходит?

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

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

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

доки на психоПГ посмотреть и shmax shmin проверить

shmax/shmin же вроде в прошлом.

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

мм... тогда сорян

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

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

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

Похоже на memory leak (или фрагментацию). Ну а пробовали смотреть, сколько памяти использует этот backend? Может, в python тоже есть какие-то средства для отладки потребления памяти?

тут косяк именно на plpython

он же создает контекст и никогда его не удаляет

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

Похоже на memory leak (или фрагментацию). Ну а пробовали смотреть, сколько памяти использует этот backend? Может, в python тоже есть какие-то средства для отладки потребления памяти?

вот тоже хотел про plpython послушать, может кто-то сталкивался

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

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

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

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

Скобок и кавычек нечётно

Спс)

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

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')

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

Ок, спс

Господа знатоки, помогите, пожалуйста или хотя-бы укажите куда копать. Есть такой запрос: 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

Вот

а проблема какая?

Проблема - не используется индекс по location.point

Но если вместо t.radius использовать константу - то всё работает замечательно

https://pastebin.com/npZ788iq

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

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

Но если вместо t.radius использовать константу - то всё работает замечательно

да, он не может в таком виде инлайнить

да, он не может в таком виде инлайнить

https://stackoverflow.com/questions/40919364/st-dwithin-does-not-use-index-with-non-literal-argument/49943387#49943387

Можно с этим что-то сделать?

Можно с этим что-то сделать?

вот выше ссылка

Спасибо, я как раз от такой реализации и побежал искать способы поочевиднее.

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

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

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

Видимо, придется переделывать сие ясделие.

ну, можно аккуратно субселектами и ручным инлайнингом это порешать

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

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

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

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

Наверное, выносил бы... Только FK на таблицу продаж, наверное?

Наверное, выносил бы... Только FK на таблицу продаж, наверное?

Ну да, оговорка )

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

Если интересно - перенес столбец с координатами в таблицу с радиусами и проиндексировал create index idx_timeline_location on timelines using gist(st_expand(st_transform(location, 2249), radius));. st_dwithin косвенно подцепил индекс.