DP
Size: a a a
2020 June 23
Н
Виноват, невнимателен. Спасибо
Не за что, нужное всегда мимо глаз проходит)
RO
Добрый вечер, коллеги! Кто нить подскажет почему запрос типа:
SELECT
Book,
Date,
MarketData,
currency,
greeks_type,
pillar_term,
sumState(original_notional * factor) AS original_notional
FROM Sensitivity
GROUP BY
Book,
Date,
MarketData,
currency,
greeks_type,
pillar_term
HAVING original_notional IN (-1., -100000.)
не имеет право на жизнь?
Clickhouse 19.15.3
SELECT
Book,
Date,
MarketData,
currency,
greeks_type,
pillar_term,
sumState(original_notional * factor) AS original_notional
FROM Sensitivity
GROUP BY
Book,
Date,
MarketData,
currency,
greeks_type,
pillar_term
HAVING original_notional IN (-1., -100000.)
не имеет право на жизнь?
Clickhouse 19.15.3
DC
Required Optional
Добрый вечер, коллеги! Кто нить подскажет почему запрос типа:
SELECT
Book,
Date,
MarketData,
currency,
greeks_type,
pillar_term,
sumState(original_notional * factor) AS original_notional
FROM Sensitivity
GROUP BY
Book,
Date,
MarketData,
currency,
greeks_type,
pillar_term
HAVING original_notional IN (-1., -100000.)
не имеет право на жизнь?
Clickhouse 19.15.3
SELECT
Book,
Date,
MarketData,
currency,
greeks_type,
pillar_term,
sumState(original_notional * factor) AS original_notional
FROM Sensitivity
GROUP BY
Book,
Date,
MarketData,
currency,
greeks_type,
pillar_term
HAVING original_notional IN (-1., -100000.)
не имеет право на жизнь?
Clickhouse 19.15.3
state нельзя сравнивать как HAVING original_notional IN (-1., -100000.)
DC
надо финализовать
DC
типа как-то так finalizeaggregation(original_notional) IN (-1., -100000.)
D
имхо там проблема в алиасинге, не?
у нас решалось даванием алиаса таблице и префиксованием везде где можно... но там тоже были баги мелкие, уже не помню
у нас решалось даванием алиаса таблице и префиксованием везде где можно... но там тоже были баги мелкие, уже не помню
RO
state нельзя сравнивать как HAVING original_notional IN (-1., -100000.)
спасибо большое
D
а не, я ерунду пишу
D
@den_crane порядок в order by очень сильно влияет на скорость сортировки?
например order by (p1,p2,p3)
будут ли запросы
примерно равноценны по скорости?
например order by (p1,p2,p3)
будут ли запросы
select * from t order by p1
select * from t order by p2
select * from t order by p3
примерно равноценны по скорости?
DC
@den_crane порядок в order by очень сильно влияет на скорость сортировки?
например order by (p1,p2,p3)
будут ли запросы
примерно равноценны по скорости?
например order by (p1,p2,p3)
будут ли запросы
select * from t order by p1
select * from t order by p2
select * from t order by p3
примерно равноценны по скорости?
select * from t order by p1 сможет использовать индексDC
остальные 2 не смогут
A
подскажите, plz, количество clickhouse серверов в яндекс-метрике? где-то видел, но забыл
DC
подскажите, plz, количество clickhouse серверов в яндекс-метрике? где-то видел, но забыл
600, число по памяти, из рассказов на конференциях
т.е. Алексей рассказывал, что было 400 потом перехали в другой кластер и т.д.
т.е. Алексей рассказывал, что было 400 потом перехали в другой кластер и т.д.
p
"not a Yandex bot" )
D
select * from t order by p1 сможет использовать индексспасибо
K
Есть какие-нибудь подводные камни при работе с очень большим количеством колонок (тысячи/миллионы)?
DT
каждая колонка это два файла в каждом парте,
больше тысяч колонок уже неоптимально
больше тысяч колонок уже неоптимально
DC
Есть какие-нибудь подводные камни при работе с очень большим количеством колонок (тысячи/миллионы)?
уже на тысяче колонок начнутся проблемы, долгая вставка жрущая кучу памяти
2020 June 24
RP
"not a Yandex bot" )
that's exactly what a Yandex bot would say