102600+ entries in 0.042s
mircea_popescu: which is just about what the web MEANS. www = "that data exploration mechanism which ocasionally puts out old data, of an unspecified age but younger than x".
mircea_popescu: anyway. this has been, at least to me, an informative excursion.
mircea_popescu: this is not so differeny from my "if you absolutely must hire shaman, hire mysql, it's cheapest"
mircea_popescu: this point has some merit, but we're reading "arbitrary" stuff not arbitrary stuff, it's addressed to the db abstraction which is allowed to handle it, not directly to pointers.
mircea_popescu: dude the fact that every other girl in your class is a slut isn't going to feed you or your baby.
mircea_popescu: davout block verification is the bottleneck in the dump-eat block process.
mircea_popescu: filtering a chain out of the soup outside like BingoBoingo is not without merit.
mircea_popescu: davout the suspicion is that relevant data may be missing from the thing, but we really dunno.
mircea_popescu: davout no he's saying it's not in the sql spec! which, considering how specwork goes, he might be even right about some version.
mircea_popescu: how about prostgres===mysql because guess what, c machine. hm ?
mircea_popescu: and i'm supposed to care about the fact that they don't know how to write a db that doesn't spit out passwd ?
mircea_popescu: and THIS is what i mean re "problems in the field". whopee, idiots who can't code still want to be "at the forefront of computing" so they made a modern db that doesn't work.
mircea_popescu: jurov no ; but i am fine with wwwtron ocasionally reading a field that has meanwhile been updated, and giving old, of an unspecified age but less than x time.
☟︎ mircea_popescu: and here's exactly the problem of superficiality : "you either expect consistency or there's no point in discussing". there's LEVELS. maybe i expect all my writes to be consistent and don't care by A CLASS of reads being consistent. this is a consistency model that's consistent.
mircea_popescu: meanwhile inconsistency within the actual db are a different matter.
mircea_popescu: you are confusing two consistencies. the problem here discussed is dirty read by www ; its consistency with the actual db is not seriously contemplated.
mircea_popescu: one cuts and the other picks. if you cut db field into "acid" i pick you out of existence.
mircea_popescu: whether i want consistency as arbitrarily defined by you is my decision, not yours.
mircea_popescu: phf here's the problem : moder(field) consists of take field, redefine it in a practically useless but superficially persuasive way, then bad_words() to whoever dares ask if your "field" solves any important questions in the field. because of course it doesn't, MIT is the premier institution in science(*) and technology(*) in the werld.
☟︎ mircea_popescu: whether i would or i wouldn't IS NOT THE DB'S DECISION, jurov .
mircea_popescu: and im supposed to be so cowed by the risk of being called mysql-sometrhing that i'm not going to say anything or i dunno
mircea_popescu: davout this is entirely my argument : they've moved the problem and call this "modern db"
mircea_popescu: because, again, a semaphore exists because the user does not know what the user is doing.
mircea_popescu: phf i am saying that if you imagine the user can be relied on to "know where the locks are and read around them" then you are therefore necessarily saying "locks are useless - user can always know what he wanted locked and simply not write there hurr"
mircea_popescu: phf think for a second : the whole FUCKING POINT of a semaphore, of any kind, is that user can't know what the other item involved is doing. if they could know, they wouldn't "avoid the locks", they'd avoid the bad write outright.
mircea_popescu: exactly how the statements {"do not allow anyone else to write here until i say" ; "let anyone read anything at any time"} amount to an "unsolved problem in cs" ? and wtf cs is this we speak of, sounds more like chewinggum-science.
☟︎ mircea_popescu: nevermind "mysql world" and "security" claptrap. the point of fact is you want me to cut off my hand so my helmet will fit.
mircea_popescu: does either of you see how this is the db writer outsourcing his incompetence on the user ?
mircea_popescu: it really should be up to operator wtf, if i want to read dirty let me read dirty what sort of decision is this for designer to make.
☟︎ mircea_popescu: you don't in general want the frontend to be able to expire your cache, let the backend do it whenever it feels like it.
mircea_popescu: mysql doesn't lock reads on write locks ; i expect any rmdbs should be capable via config.
mircea_popescu: asciilifeform as to "how to make www respond", you use the method we were discussing last time, whereby www is a cached image and if out of date tough for viewer ; as to nursery "do we have this ? how about this?" you really want the db to do that for you, it's ~the only thing it;s good for.
mircea_popescu: so : if loading the whole batches of keys through the user-wwwform process is what 99% of the machine time goes to, then yes, put the batches into a single, sorted query, make the workmem should be 256mb or 2gb or w/e it is you actually need to cover your query (yes this can be calculated, but can also be guessed from a few tries) and then run bernstein after every such query, on the db not on "nursery" (which yes, it's a ter
mircea_popescu: if this is the path you must walk to go from solipsist-alf to socially-integrated-alf i can see it, but hurry it up already it's irritating.
mircea_popescu: you are getting to where it is in principle not worth anyone's time to talk with you, because your response is random nonsequitur.
mircea_popescu would not be particularly surprised if served with 100mb of query as per above postres wouldn't just fall over.
mircea_popescu: this is a piddly excuse, "no duplicate logic", case of luser with wwwform and case of 100k keys in batch form are different enough to warrant duplicate logic. that's why computers even exist, to account for such level of difference in code.
mircea_popescu: yes, well, that's then the problem. they should go in as a single query the size of the batch, with the items sorted within it
mircea_popescu: would you stop with these bizarro deflections, they neither impress nor persuade, but they do give you an ugly image.
mircea_popescu: uh. then why do you put the keys in in batches if you're not... putting them in in batches ?
mircea_popescu: it has ~some~ ability to precompile your queries, which is somewhat like linking object code.
mircea_popescu: yes but it has this convenient hole through which you can go in, which is - implement bernstein IN sql.
mircea_popescu: which yes takes some work, but not quite as much as the other variant.
mircea_popescu: bitcoin wants its own fs. ANOTHER way, is to use the means the db already offers for this.
mircea_popescu: you're not addressing the idea. currently you use a pile of c code you labeled for purely personal reasons "a db" to store some data for you, and another pile, you labeled phuctor, to bernstein and do other things on the db-stored data. because the interface is the bottleneck, it then becomes clear you must merge this. one way is to merge by lifting the db code and putting it into phuctor, making it you know, its own db like
mircea_popescu: and you do it as prepared queries, which get precompiled to a degree
mircea_popescu: you implement bernstein IN the db. it is actually a programming language.
mircea_popescu: though i am unaware anyone ever implemented this ; because, of coruse, i am unaware anyone used the guy's algo for any other purpose than gawking.
mircea_popescu: trinque 's idea, bernstein as prepared queries, may be a gain.
mircea_popescu: you can also set bgwriter_lru_maxpages to 0 and disable background writing altogether