4 ms·
PostgreSQL like many SQL engines has real cost in doing separate queries, and the query analyser does a lot of work to "understand" what you mean (and may need
by geocar 9y ago
PostgreSQL like many SQL engines has real cost in doing separate queries, and the query analyser does a lot of work to "understand" what you mean (and may need a lot of guidance in the form of indexes), but in kdb+, a lot of these queries are simple and obvious to a q programmer, and doing it across multiple statements creates opportunities to understand what you're looking at -- and with little-to-no cost.
1.
fake:2017.02.01+til 28
t:select sum amount by legit:payment_date.dd from payment
t:update fake:legit from a where legit in fake.dd
select from t where amount > 2000
2.
string[2]," times "," 2 equals",string[2*2]
3.
t:desc select sum amount from payment by customer_id where payment_date.mm = 4, payment_date.dd within 10 13
/ or obviously clearer if you know the year:
/ t:select ... where payment_date within 2017.04.10 2017.04.13
d:exec distinct customer_id from t where amount > 30
select first_name, last_name, email from customer where customer_id in d
only want the top 5?
d:5#d;
4.
Tables are a data type (unlike SQL) so this is much simpler:
tbl_1:([] some_day:2018.04.01+til 15; an_amt:2.43+2.266*til 15)
tbl_2:([] some_day2:2018.05.16+til 16; an_amt2:15.43+1.03*til 16)
5.
No need for a query:
count film
count where film.rating="G"
or remembering this is a vector language:
sum film.rating="G"
count of each rating needs a query though:
select count i by rating from film
6.
An excellent opportunity to see value sharing syntax between function application and indexing:
m:`gold`bronze`platinum`silver!`gold_group`bronze_group`platinum_group`silver_group
m:m!`$string[m:`gold`bronze`platinum`silver],\:"_group"; /shorter
update member_status:m member_status from `reward_members where member_status in key m
7.
awards_to_honor:select expense_amt, member_status from reward_members where member_status=`gold_group
save `:awards_to_honor.csv
- klibertp 9y ago> a lot of these queries are simple and obvious to a Q programmer I'm not sure if it was you, but I most definitely saw a couple of posts like this on HN. Each time I had just one wish: for the poster to provide an explanation, preferably from the basics, of what is going on. As a programmer, due to my hobby, I learned a lot more programming languages than average and am pretty confident in my ability to learn new ones, yet K and Q elude me completely. Every time I get interested in it, I struggle with its complete lack of entry-level documentation. I learned J, and while it's similarly impenetrable at first, there are tons of good documentation on J wiki. With Q I couldn't find anywhere near that amount of explanations. So, I'm not against pasting Q snippets in comments, but I think they would bring much, much more value if accompanied with a detailed explanation of both syntax, semantics, and library functions. As it stands, even things I thought I know, like that : means assignment, only add to the confusion, because looking at your code I see that apparently it sometimes means something else entirely...
- is0tope 9y agoI usually recommend Q for Mortals. Vhttp://code.kx.com/q4m3/ http://code.kx.com/q4m3/ The thing I love is that the SQL and regular programming syntax can be mixed. For instance, if I wish to apply a lambda function for each group I can do, eg: select result: {lambda code here...} column by category from table Since a table is implicitly a list of dictionaries under the hood, you can iterate over a table where each column will be a dictionary. Tables and dictionaries are first class objects in q, so it is a lot easier to reason about certain manipulations as they are essentially the same as if you had used regular code. One issue I've always had with SQL itself is that I learned KSQL first, and the way many things are done in regular sql just seem strange.