LINUX.ORG.RU
ФорумTalks

Я открыл свой SQL движок

 , , ,


0

3

Звезды ставить сюда: https://github.com/resetius/qumirdb

Как это сейчас модно, у меня есть нативная интеграция с rust

CREATE MODULE orbital LANGUAGE rust AS $$
#[no_mangle]
pub extern "C" fn orbit_is_neo(a: f64, e: f64) -> bool {
    a * (1.0 - e) < 1.3
}
$$;

CREATE FUNCTION orbit_is_neo(a DOUBLE, e DOUBLE) RETURNS BOOL
SET MODULE TO orbital;

SELECT designation FROM sbdb_objects
WHERE orbit_is_neo(a, e) AND e < 0.3;

А еще с Кумир:

CREATE MODULE orbital
LANGUAGE kumir
AS $$
алг вещ orbit_perihelion_au(вещ a, e)
нач
    знач := a * (1.0 - e)
кон

алг вещ orbit_aphelion_au(вещ a, e)
нач
    знач := a * (1.0 + e)
кон

алг вещ orbit_period_days(вещ a)
нач
    | Третий закон Кеплера для гелиоцентрической орбиты, a в а.е.
    знач := 365.2568983 * sqrt(a * a * a)
кон

алг вещ orbit_mean_motion_deg_day(вещ a)
нач
    знач := 360.0 / orbit_period_days(a)
кон

алг лог orbit_is_neo(вещ a, e)
нач
    знач := orbit_perihelion_au(a, e) < 1.3
кон
$$;

SELECT
    a.designation,
    t.timestamp AS timestamp,
    a.m + orbit_mean_motion_deg_day(a.a) * (t.timestamp - a.epoch) AS mean_anomaly,
    orbit_perihelion_au(a.a, a.e) AS perihelion_au,
    orbit_aphelion_au(a.a, a.e) AS aphelion_au
FROM unnumbered_asteroids a
CROSS JOIN timestamps t
WHERE
    orbit_is_neo(a.a, a.e)
    AND a.e < 0.1
    AND t.timestamp >= 61564
    AND t.timestamp < 61565
    limit 10;

Работают сколько угодно сложные запросы

with ws as
  (select d_year AS ws_sold_year, ws_item_sk,
    ws_bill_customer_sk ws_customer_sk,
    sum(ws_quantity) ws_qty,
    sum(ws_wholesale_cost) ws_wc,
    sum(ws_sales_price) ws_sp
   from web_sales
   left join web_returns on wr_order_number=ws_order_number and ws_item_sk=wr_item_sk
   join date_dim on ws_sold_date_sk = d_date_sk
   where wr_order_number is null
   group by d_year, ws_item_sk, ws_bill_customer_sk
   ),
cs as
  (select d_year AS cs_sold_year, cs_item_sk,
    cs_bill_customer_sk cs_customer_sk,
    sum(cs_quantity) cs_qty,
    sum(cs_wholesale_cost) cs_wc,
    sum(cs_sales_price) cs_sp
   from catalog_sales
   left join catalog_returns on cr_order_number=cs_order_number and cs_item_sk=cr_item_sk
   join date_dim on cs_sold_date_sk = d_date_sk
   where cr_order_number is null
   group by d_year, cs_item_sk, cs_bill_customer_sk
   ),
ss as
  (select d_year AS ss_sold_year, ss_item_sk,
    ss_customer_sk,
    sum(ss_quantity) ss_qty,
    sum(ss_wholesale_cost) ss_wc,
    sum(ss_sales_price) ss_sp
   from store_sales
   left join store_returns on sr_ticket_number=ss_ticket_number and ss_item_sk=sr_item_sk
   join date_dim on ss_sold_date_sk = d_date_sk
   where sr_ticket_number is null
   group by d_year, ss_item_sk, ss_customer_sk
   )
 select 
ss_sold_year, ss_item_sk, ss_customer_sk,
round(ss_qty/(coalesce(ws_qty,0)+coalesce(cs_qty,0)),2) ratio,
ss_qty store_qty, ss_wc store_wholesale_cost, ss_sp store_sales_price,
coalesce(ws_qty,0)+coalesce(cs_qty,0) other_chan_qty,
coalesce(ws_wc,0)+coalesce(cs_wc,0) other_chan_wholesale_cost,
coalesce(ws_sp,0)+coalesce(cs_sp,0) other_chan_sales_price
from ss
left join ws on (ws_sold_year=ss_sold_year and ws_item_sk=ss_item_sk and ws_customer_sk=ss_customer_sk)
left join cs on (cs_sold_year=ss_sold_year and cs_item_sk=ss_item_sk and cs_customer_sk=ss_customer_sk)
where (coalesce(ws_qty,0)>0 or coalesce(cs_qty, 0)>0) and ss_sold_year=2000
order by 
  ss_sold_year, ss_item_sk, ss_customer_sk,
  ss_qty desc, ss_wc desc, ss_sp desc,
  other_chan_qty,
  other_chan_wholesale_cost,
  other_chan_sales_price,
  ratio
limit 100;

Есть как нативное исполнение так и в браузере: https://db.qumir.dev

★★★★★
Ответ на: комментарий от Bad_ptr

На сайте про линкс это очень странный вопрос.

imul ★★★★★
()
Ответ на: комментарий от Bad_ptr

Всё только лишь для того, чтобы упомянуть Rust

PPP328 ★★★★★
()

А вообще мне интересно сможет ли полностью jit-based движок побороться с движком на написанных руками simd-ядрами таким как duckdb. Пока у меня отставание не сильное и есть запас мест где можно прям хорошо улучшить.

Reset ★★★★★
() автор топика

Работают сколько угодно сложные запросы

Ещё бы они не работали. А что со скоростью работы? Всмысле оптимизатор плана исполнения хороший?

firkax ★★★★★
()
Ответ на: комментарий от firkax

Хороший. Применил все свои знания полученные при работе над YQL. Порядок join’ов меняется с помощью cost-based dp алгоритма.

Reset ★★★★★
() автор топика

highload

Требуются пруфы!

mord0d ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)