phf: apparently that's not how they do things down south. once a grudge always a grudge. fine. we can agree not to talk to each other at all, nor mention each others names. i was sticking to that policy, and it worked fine for me. good day.

phf: then why speak to me at all? i was arguing in good faith, as an attempt to move on from our previous alteration

phf: if that was such an obvious assumption, then why evade addressing it? that would've saved the whole thread! my assumption was ~very obvious~ as you yourself state ~all through the thread~, because ~that's what i assumed~

phf: that's why i asked you point blank if you're talking about reading code, omg

phf: you clearly have some twisted issues related to me. ~that was not my intent~. ~i genuinely think that you were speaking of pulling levers~ ~because there's nowhere in the thread where you attempted to dissuade me of my notion~

phf: if anybody else can find a trinque quote that says an equivalent of http://btcbase.org/log/2017-04-10#1641538 i will apologize, otherwise i guess this stands. ☝︎

phf: but that's a roundabout way, and you could just read about it in a blog. if the position is that "we should study postgresql source code extensively, as a necessary prerequisite to writing our own database", then i would agree with you, but that doesn't seem to be what you're saying ☟︎

phf: trinque: well, then why not say it when i asked if you were talking about crackign open the source code? now i actually think that you're lying

phf: well, that wasn't a rhetorical question, i was interested. so the second question remains, what does knowing entail in this case

phf: but i don't think you're even talking about cracking open the covers? so what does the knowing of these "exceptionally well" things entail?

phf: i'm not sure it's worthwhile to fetishize that quality either. if you attempt to write a db from scratch, postgresql internals is not the first place to look.

phf: in db sucks threads you necessarily talk about pain points. i don't think ~anybody~ here disputes that postgresql is a solid piece of engineering

phf: ok, i guess we both know what the problem is. my solution is "study db related algorithms until you know enough to write a db", your solution, unless i misunderstand, seems to be "use an existing database a lot". i don't understand how learning, say, postgresql will get you from not knowing anything about db internal design to writing your own ☟︎

phf: but i don't think that working with a black box of rdbms will

phf: the "glue" point is a strawman, because you don't know how i write my code. as far as problem/solution though

phf: what ~is~ the point you're trying to make? you say things, i address them, you immediately move on to some other point

phf: and you're wrong as far "everyone uses sql11". merril lynch is famous for storing massive datasets in kdb. deutsche bank uses kdb as well as a handful of other datastores (i have some knowledge here), also two of the banks that i consulted for used object stores. that's just the projects that i consulted

phf: trinque: you've asked a question, that i was about to answer, but it turned out to be a rhetorical question, that you then used as a platform to make a political point, yes

phf: tmsr work is primarily defined by its voluntary nature, if i had to do things same way i do it at the office i wouldn't bother. ascii doesn't know intricacies of psql from his day job, and i think it's cruel and inhuman to make him study psql ~as part of tmsr work~. it's not the kind of know how you get to learn by sitting down with a cup of tea and a large printout.. ☟︎

phf: they laughed at me when i said btcbase doesn't use a database, who's laughin now ☟︎

phf: i take it phuctor is more like btcbase. a couple of thousand requests a day, with an occasional massive bot spike

phf: there's a benedictine monastery in bangalore where make italian style cheese. considering how bad cheese is otherwise in the country, i'm contemplating making a pilgrimage to bangalore just to see how they do, next time i'm there