199800+ entries in 0.121s
a111: Logged on 2017-04-10 15:25 asciilifeform: lol,
thousand 'postgres: phuctor phuctor [local] SELECT' processes zombieing
shinohai imagines Vitalik reading
the logs an
thing mircea_popescu meant `Asi` is a new groundbreaking algorithm .....
mircea_popescu: you know, when
trump gets elected. when
the niggers who figured
they were gonna use "consensus"
to get
the delicious chicken fail
to get
the delicious chicken.
ben_vulpes: "just remember you can't
take your words back,
these aren't Ethereum
transactions"
CompanionCube: besides, plush pillows are normally good for cuddling when you want
to
trinque: and I don't see
that you get much "culture of honor" without it
trinque: probably about as southern as it gets,
that one
trinque: phf: one
thing
they don't do is speak for
the other,
then proceed from
there as if it'd been said
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
trinque: I'm not defending every fucking "OP is a redditard" you
throw at me
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~
trinque: that running forward with a bare assumption and
then spending
the whole
thread
trying
to smash opponent into it has been
the rule with you
trinque: you did
that aiming
to pin me on something easily argued
trinque: you made
the assumption
that when I was speaking of
the
things merits, I was speaking of what,
the lever you pull and not what it actuates?
a111: Logged on 2017-04-10 19:35 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
trinque: I could quote myself several
times in
this
thread saying exactly
that.
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
☟︎ trinque: about done having my character attacked by
this guy.
trinque: I described how
the
thing writes rows
to disk.
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
trinque: I've both read postgresql source, several other db
turds, written own, extended pg and mucked about heavily in internals
phf: that still doesn't answer my question, but
the question is at
the core of my point. you don't read existing implementations, you don't attempt
to write new implementations, you're ~using~ a system
that does
these
things for you. so what is ~knowing~ in
this case.
trinque: the re-implementor of modern computing doesn't dispense with
these as "you didn't really need
that"
phf: well,
that wasn't a rhetorical question, i was interested. so
the second question remains, what does knowing entail in
this case
trinque: pointedly, where's my
transactional, versioned, fault
tolerant, *persistent* lisp system?
trinque: later versions pointing upward
to previous
trinque: and in fact does;
that's how
the versioning works
trinque: pg's versioned on-disk heap could've held
trees as well as rows, eh?
trinque: whole point having been
that
there are useful items in
there
that all got welded
together
☟︎ trinque: what'd you expect as a response
to
that first bit?
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
trinque: yep, I'm out of
this
thread.
trinque: and I'd question
the ability of anyone
to replace it who didn't bother with
that list of
things which has fuck all
to do with SQL
trinque: the
things pg did exceptionally well never come up in
the "omg db sux"
thread
trinque: neither asciilifeform nor I did in particular cases due
to practical
tradeoffs of
taking
that
time
trinque: and I agree with phf
that my recourse is
to write
the
thing I want
trinque: I don't criticize
that he used it; I do all
the
time for lack of alternative which has
the properties I want
trinque: asciilifeform did, so I didn't mind
trying
to help with
that car wreck, having been in plenty of
them myself
trinque: I'm sure I've said SQL dbs are
terrible a hundred
times now.
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: yes, you can't sit down with a collection of independent algorithms combined in a specific way and use it in a different way without writing extra code, but
that's what repl is for
phf: but i don't
think
that working with a black box of rdbms will
phf: writing out each one of
those concerns separately will
teach you how
to do it (or whether it can even be done, like with "atomic file system")
phf: the "glue" point is a strawman, because you don't know how i write my code. as far as problem/solution
though
lobbes: I do come from
the 'let
the data speak for itself' school, so
that makes sense
to my limited understanding
trinque: the guy who loves hard
theory is going
to claim
the latter always derives from
the former
trinque: you have
to be able
to audit *two*
things;
the code, and
the data, and independently
lobbes: But re: fits in head. Isn't phf's/alfs argument
that you cannot really even audit said generalized glue?
trinque: the database as (extremely poorly) implemented by sql rdbms is a generalization of
the glue
trinque: that is a statement of
the ~problem
trinque: I can't sit down with something like
that and ask it ANYTHING
a111: Logged on 2017-04-10 16:37 phf: well, right, but you're not going
to learn how
to db by ~running~ databases.
the whole "db"
thing is an illusion anyway. rtrees, btrees, indexes, locking mechanisms, mvcc are all concrete algorithms,
that you can implement in an adhoc manner for your
task at hand and actually see how
they work and what
they do.
phf: trinque: ~what is
the point you're
trying
to make~
trinque will re-engage
this in a bit
trinque: phf: I'm having
the same experience over here!
shinohai: The only way
to
truly settle
this matter is with swords.
phf: what ~is~
the point you're
trying
to make? you say
things, i address
them, you immediately move on
to some other point
trinque: (he's going
to claim I'm arguing for ubiquitous SQL again and miss
the point)
trinque: I'll
tell you;
the glue between
them by weight comes
to dominate
a111: Logged on 2017-04-10 16:51 phf: most of
them ~also use sql~. but likewise
there's no such
thing as "the database"
there's also no such
thing as "the database company uses
to store its data". banks
typically have 50-100 different large data stores,
that serve different purposes
jhvh1: shinohai:
The operation succeeded.
trinque: say atomic writes on a filesystem,
transactional versioning atop
that, ...
trinque: so we agree
that
this
thing called "database" is really distinct
tools which some idiot welded
together
☟︎ phf: but on
the other hand also anything involving objects of non-trivial
topology (that's where you want object stores)
phf: anything involving real
time data, anything involving
time series, anything involving datasets > 100mil
phf: but
the reason
that
they don't all use sql, is because sql is really bad for certain narrow kinds of
tasks and suboptimal for a slightly larger set of
tasks
phf: most of
them ~also use sql~. but likewise
there's no such
thing as "the database"
there's also no such
thing as "the database company uses
to store its data". banks
typically have 50-100 different large data stores,
that serve different purposes
☟︎ trinque: I claimed
that
they will satisfy all
the requirements by whichever means
they choose
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
trinque: my point was
that
the customer for
the item has
these requirements; what does
the item which satisfies
them begin
to resemble?
trinque: phf: ah,
then wasn't my intention
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
trinque: what problems do you encounter at
that scale