11:48 <@EastByte> I don't get it, quakenet's spam protection limits all users two one message per two seconds but webchat clients basically have no such limit 11:53 <+Rafael> xD 11:58 <@deen> EastByte: haha 12:02 <@EastByte> I'm currently working on a nim irc bot for quakenet that supports quakenet's auth system 12:03 <@EastByte> but it's hard to get user auth information if the /whois command is limited two once per two seconds 12:03 <@EastByte> s/two/to damn it 13:08 <@EastByte> whoops, I was wrong, the message throttle was client side 15:51 <+minus> You have throttling in your bot and don't even know about it? 15:54 <@EastByte> minus: actually not, but I guess when I noticed the throttlling I probably tested it via my weechat client sending commands to the bot 15:54 <@EastByte> and didn't notice that weechat itself throttled 16:01 < Sav_> Hey! On Brazil and USA zCatch servers are something wrong with ranking ;). TOP 5 shows wrong results. 16:03 <+Sav_> and on Chile as well! 16:03 <+Sav_> You should check this 16:37 <@deen> hi Sav_ 16:37 <+Sav_> hi deen 16:37 <@deen> Sav_: it has a wrong ordering, right? 16:37 <+Sav_> yes 16:37 <@deen> ok, thanks 16:37 <+Sav_> but why? 16:37 <+Sav_> because of mariandb? 16:37 <@deen> Oh, are you Savander? 16:38 <+Sav_> yes 16:38 <+Sav_> :p 16:38 <@deen> I just wanted to write "I didn't write that code, Savander did, ask him" 16:38 <@deen> :P 16:38 <@deen> Well, I don't know. They are all connected to USA database 16:38 <@deen> and yes, it's mariadb and I believe HMH wanted to update it to MariaDB 10.1 16:39 <@deen> which is probably the cause 16:39 <+Sav_> huh 16:39 <+Sav_> but on GER it works great 16:39 <+Sav_> you have old one? 16:39 <@deen> GER has MariaDB 5.5 16:39 <@deen> USA 10.1 16:40 <@heinrich5991> huge step :o 16:40 <@deen> they skipped 6-9 16:40 <@deen> :P 16:40 <@heinrich5991> ah ^^ 16:40 <@deen> 5.5 was the old version number taken from MySQL 16:40 <@deen> then they jumped to 10 to avoid confusion with new MySQL version numbers 16:40 <@heinrich5991> until mysql releases v10 16:40 <@heinrich5991> :D 16:41 <@deen> I believe the expectation is that Oracle will kill MySQL before that can happen ;) 16:41 <@heinrich5991> ^^ 16:41 <+Sav_> sooo, im not able to fix it 16:41 <+Sav_> i never worked with mariadb 16:41 <@deen> Sav_: I'll play around with the query 16:41 <@deen> and look into why it doesn't work 16:42 <@heinrich5991> (mariadb = mysql for all intents and purposes AFAIK) 16:42 <@deen> yeah, mariadb has the original developers of mysql 16:42 <+Sav_> queries aren't complicated 16:43 <+Sav_> so i should work, but it doesn't :P 16:43 <+Sav_> i have problems with my keyboard 16:43 <+Sav_> some keys doesn't work :( 16:45 <@deen> new keyboard or old? 16:45 <@deen> on old ones take out the key caps and clean them 16:46 <+Sav_> old one 16:47 <+Sav_> after 2 year on ddnet 16:47 <+Sav_> my english is still bad 16:47 <+Sav_> as f**k 16:48 <@EastByte> don't worry, my english is bad although I talked in developer channels for years 16:52 <+Sav_> I should to learn, but im lazy 16:59 <+minus> replace mysql/mariadb with a real database :3 16:59 <@deen> minus: postgresql or what? 16:59 <@EastByte> a non-relational database! 16:59 <+minus> deen: exactly 17:00 <@deen> minus: I know, but that's work and from what I heard it might need more RAM 17:00 <@deen> and not sure what the state of replication is in postgres 17:03 <+minus> i think it's external projects, though master-slave might be integrated 17:03 <+minus> haven't seen it consume a lot of RAM fwiw 17:04 <@deen> have you been running it alongside 10 servers on 256 MB of RAM? :P 17:04 <+minus> but yeah, why switch if it works (except it doesn't, right?) 17:04 <@deen> well, the query is wrong 17:04 <@deen> it assumes some ordering that was just there by coincidence but not specified 17:05 <+minus> ah, i know that 17:05 <+minus> had the exact same problem earlier today 17:05 <+minus> on one of the machines here the pg server uses 25M of RAM, plus about 10M per connection (separate processes) 17:05 <@deen> nice 17:06 <+minus> makes about 3GB of total RAM usageā€¦ 17:06 <@EastByte> so many connections? 17:06 <+minus> yes 17:06 <@deen> I hope I learn something about databases soon 17:06 <+minus> should be fixed, but cba 17:07 <@deen> (starting a job working on a database implementation in 10 days) 17:07 <@EastByte> like javascript? 17:07 <+minus> RDBMS? 17:07 <+minus> or hip nosql stuff? 17:08 <@deen> rdbms, in-memory, column-oriented 17:08 <@EastByte> completely in-memory? 17:08 <@deen> yes 17:08 <@EastByte> that's nice 17:08 <@deen> need more performance! 17:10 <+Sav_> hip nosql o.o 17:11 <+Sav_> It's weird to read all of it. Very often you says something, what is totally new to me. :PP Im ashamed of my lack of knowledge. 17:19 <+minus> what's "column oriented"? 17:19 <@EastByte> sounds like relational to me 17:20 <@deen> minus: instead of storing rows, store columns 17:20 <@deen> for the tables 17:21 <@deen> faster to traverse a single column in memory and compresses better 17:27 <@deen> actually this does smell like a mariadb bug to me or I don't understand SQL myself 17:28 <@deen> ok, I didn't understand SQL: https://mariadb.com/kb/en/mariadb/why-is-order-by-in-a-from-subquery-ignored/ 17:36 <@deen> so our approach for /rank and /top5 is not standard compliant and I don't see a way to fix it, just work around it :/ 17:39 <+Sav_> so, ddrace don't worka also? 17:41 <@deen> ddrace works by chance 17:41 <+Sav_> ? 17:41 <+Sav_> it was pretty the same 17:41 <+Sav_> and it is 17:41 <@deen> because it modifies the temporary table a bit more by calling group the "order by" is not optimized away 17:41 <@deen> but in zcatch group is not required so "oder by" is optimized away and it stops working 17:43 <+Sav_> wait. so on ddrace, script makes temporary table, then "order by" is used on it? 17:43 <@deen> yes 17:44 <+Sav_> okay i understand, so zcatch "old" version is less optimized>?: p 17:44 <@deen> should be fixed now 17:44 <@deen> yeah, the old mariadb didn't do that optimization 17:45 <@deen> but ideally we would have a standard-compliant way of calculating the ranks 17:55 <+Sav_> what you changed? 17:56 <@deen> i added a useless "limit" in the subquery to make sure this optimization can't be done 17:56 <+Sav_> Limit 18446744073709551615 17:56 <+Sav_> ?:o 17:56 <@deen> yes :P 17:57 <+Sav_> that's the fix? 17:57 <+Sav_> xD 17:57 <@deen> yes, with an additional subquery i think 17:58 <+Sav_> okay, i see 18:00 <+Sav_> i didn't expect that. 18:00 <+Sav_> ;p 18:19 <+nameless-tee> Interesting. 18:20 <+nameless-tee> Guys, I have a question. 18:20 <+nameless-tee> I want to merge table record_race with record_teamrace for my ddnet stats project. But I realized that it's not a trivial task. Same finish records in both tables may have different timestamps. And since there are maps like this: https://ibin.co/2lGGMMPzeukF.png I can't use simple joins. Does anyone have any ideas? 18:21 <+nameless-tee> Maybe I'll try sql function timestampdiff(), to link records between the tables, but it looks like timestamps may vary in different ways. 18:43 <@deen> nameless-tee: well yeah, there is no good way to join them. I would have done some heuristic with diffs but for us joining these tables did not work in the end 18:51 <+nameless-tee> I see. Thanks deen. 18:52 <@deen> there's a github issue if someone wants to work on joining the tables and normalizing our db 19:02 <+nameless-tee> Yes, I saw it. Good work.