2_
потому что видимо вы не сталкивались со статистическими запросами, это может быть такая простыня сотен в 5 строк, например.
Size: a a a
2020 June 13
2_
я повторяю ваши лолы не придают вам важности, то что вы пишете очень несерьезно выглядит.
TS
Проранжируйте данные с сортировкой по айди. Потом только 1 ранга строки суммируйте.
Да, вы правы, так можно было бы сделать, но у нас и сумма не просто сумма - То, что суммируется - это объект, в котором есть значение и единица измерения, а сумма - это объект из сумм по разным единицам измерения. Так что функцию суммы все равно писать, а раз уж писать, то сразу с вохможностью этакого дистинкта.
2_
что значит обычная, это select. я думаю вам либо стоит лучше формулировать ваши аргументы, либо оттачивать ваше ЧСВ в другой ветке.
2_
можно я это себе запишу.
Д
Тагил. В цте пишете склект и роунамбер с партишном по айди. Потом этот алиас Селект те с фильтром по полю роунамбера = 1
Ð
Да, вы правы, так можно было бы сделать, но у нас и сумма не просто сумма - То, что суммируется - это объект, в котором есть значение и единица измерения, а сумма - это объект из сумм по разным единицам измерения. Так что функцию суммы все равно писать, а раз уж писать, то сразу с вохможностью этакого дистинкта.
выглядит как простецкий кастомный агрегат
TS
Ð
выглядит как простецкий кастомный агрегат
Да, мы реализовали его и на С и на PGSQL, но на PGSQL на базе 50000 строк работает 5 секунд, что очень много. Хотя на C работает 0.1сек, вот и думаю попробовать plv8
Ð
Да, мы реализовали его и на С и на PGSQL, но на PGSQL на базе 50000 строк работает 5 секунд, что очень много. Хотя на C работает 0.1сек, вот и думаю попробовать plv8
вот я и говорю - надо переехать с амазона на более дешевый и быстрый дедик, и юзать все возможности без ограничений
Д
Тагил, ничего не понял.)
TS
Тагил, ничего не понял.)
create or replace function common.sum_value_transition(
state common.sum_value_state,
val numeric,
unit integer,
id integer
)returns common.sum_value_state AS $$
declare
i integer;
accum numeric;
BEGIN
FOREACH i in array state.ids
LOOP
IF i = id THEN
RETURN ROW(state.ids, state.accum);
end if;
END LOOP;
IF jsonb_exists(state.accum, unit::text) THEN
accum = jsonb_extract_path(state.accum, unit::text)::numeric + val;
ELSE
accum = val;
end if;
RETURN ROW(id || state.ids, state.accum || jsonb_build_object(unit::text, accum))::common.sum_value_state;
END;
$$ LANGUAGE plpgsql;Ð
50 тыщ строк это вообще очень мало для агрегата такой сложности, он даже на пгскл должен летать за долю секунды
TS
Ð
50 тыщ строк это вообще очень мало для агрегата такой сложности, он даже на пгскл должен летать за долю секунды
А он не летает...
Ð
а это точно агрегат, а не итератор?
Ð
еще и жсон, ух
Ð
понятно почему он тормозит
TS
Ð
понятно почему он тормозит
Без json тоже тормозит. Похоже, дело в массиве.
Д
Ууу. Да. Летать не будет.)
p
100кк пользаков это 400мб. Они и так в кэше у сервак будут. И сервак с ними быстрее буде работать чем вы вашим кодом на бэке. Который небось ещё в конте в кубе на полудохлой машине.
нет, не в кубе и все не так просто. у каждого пользователя толпа балансов(деньги, смс, минуты, whatever), списание с этих балансов происходят параллельно и по разным наборам правил(серфить в инете во время разговора + смс, например, а стоимость услуг вообще зависит от времени суток) и с одного баланса у вас тратятся услуги для всей семьи(friends & family). И отвечать на все запросы надо за 50ms
Ð
возможно надо попробовать сделать это по-нормальному через group by и через агрегаты