Почему Erlang отказывает на больших последовательностях?
Вы можете превратить свой подзапрос в JOIN, чтобы его результат был доступен во внешнем запросе:
SELECT c.sid, c.pid, c.cost, c1.avg_cost
FROM catalog AS c
INNER JOIN (SELECT pid, avg(cost) AS avg_cost FROM catalog GROUP BY pid) c1
ON c1.pid = c.pid
WHERE c.cost > c1.avg_cost
PS: в исходном запросе вам не нужно было GROUP BY, поскольку Вы не использовали агрегатные функции во внешнем запросе. Кроме того, исходя из ваших данных кажется вероятным, что вам не нужна функциональность DISTINCT.
4 ответа
Ваша ОС может иметь предел по умолчанию на размер пользовательского процесса. На Linux можно изменить это с ulimit.
Вы, вероятно, хотите выполнить итерации по этим 64 000 000 чисел, не нуждаясь в них всех в памяти сразу. Ленивые списки позволяют Вам написать код, подобный в стиле к коду list-all-at-once:
-module(lazy).
-export([seq/2]).
seq(M, N) when M =< N ->
fun() -> [M | seq(M+1, N)] end;
seq(_, _) ->
fun () -> [] end.
1> Ns = lazy:seq(1, 64000000).
#Fun<lazy.0.26378159>
2> hd(Ns()).
1
3> Ns2 = tl(Ns()).
#Fun<lazy.0.26378159>
4> hd(Ns2()).
2
Кроме того, оба окна и Linux имеют пределы на максимальный объем памяти, который может занять изображение, Как я вспоминаю на Linux, это - половина гигабайта.
Реальный вопрос состоит в том, почему эти операции не делаются лениво ;)
Возможно ответ новичка (я - Java dev), но JVM искусственно ограничивает объем памяти, чтобы помочь обнаружить утечки памяти более легко. Возможно, erlang имеет в распоряжении подобные ограничения?
Это - функция. Мы не хотим, каждый обрабатывает для потребления всей памяти. Это как блок предохранителей в Вашем доме. Для безопасности нас всех.
Необходимо знать, что erlangs модель восстановления понимает способ, которым они позволяют процессу просто умереть.