200900+ entries in 0.125s
trinque: asciilifeform: if stuck on python, which I grant is practical, can't really refuse
the customary sins
to make it go
a111: Logged on 2017-04-07 06:35 CompanionCube: 'An attacker within range may be able
to execute arbitrary code on
the Wi-Fi chip'
mircea_popescu: are
there any known documented and running cl-anythings more or less
the size phuctor'd be ?
trinque: python's slower, and astonishingly so when
threading
mircea_popescu: open question whether cl would be fast enough.
though i know
there's some people itching
to answer it.
trinque: haha, but hey sbcl is
threaded and hunchentoot exists.
trinque: oh I proposed nothing for
this fractal hell!
trinque: because GIL or whatever
they called
the lock
trinque: so... lol.
the other insanity people commit here is starting n pythons
trinque: irc could just
tell you when done
trinque: which is only a
thing because www is 'daddy buy me a pony now!'
Framedragger: (when you query a mat view, data is returned directly from it, without
touching
the source live
table)
Framedragger: mircea_popescu: in materialized view, postgres can persist results of query in
table-like form. so it *does* cache
them; hence you can't say it's convenience only.
trinque: thing's designed for parallelism yes, but of
the same exact data in same spot is a big ask
trinque: and keeps him from reading
the same
table he's writing
trinque: it's a speedup for someone loading
the stats page
mircea_popescu: trinque> materialized views are nothing more
than a named query which stores its results in a
table <<
this is a convenience not a speed-up
trinque: it grew beyond
this scope
the same reason bash did, or anything else
that was originally a user interface
Framedragger: btw, i once screwed around with memoization in flask. iirc something can be done here as well, asciilifeform (it may be as
trivial as adding a decorator before
the function which handles GET request)
trinque: it's a goddamned spreadsheet; you're supposed
to compute elsewhere and
then fart your results in
there so somebody managerial can ask it questions
trinque: so here's what relational db was supposed
to be for, like bash originally had a 'supposed
to be for'
Framedragger: ...no, lol,
the *results* are 'cached', you still regen html (but
this is computationally
trivial neh)
trinque: however it may be saner
to completely divorce
the algorithmic part from sql
trinque: these as queue
tables for stages of work are also useful
trinque: can cron
the "refresh materialized view"
shinohai: lol Jason Dreyzehner "Head of Design" at buttpay followed me on
twitter. Perhaps staring at
T&A will be useful in making UI decisions.
trinque: materialized views are nothing more
than a named query which stores its results in a
table
Framedragger: obtw which postgres version on phuctor asciilifeform?
those
two features not available in old versions. i don't remember which ver is in debian stable
Framedragger: again, no, and as per ACID, no dirty reads (*not a bad
thing here*)
Framedragger: not afaik.
these are
to do with *reading* only. but
trinque may chime in
Framedragger: index-only scans allow
to search in a
table without 'touching', or 'locking'
the actual rows (which may be simultaneously written-to, at
the same
time)
Framedragger: asciilifeform: have you
tried postgres index-only scans? have you
tried materialised views? if not,
the "postgres must die" sounds sorta surface-level, imho
mircea_popescu: (ftr, at least once in itgs history
trilema updated 6.5k
times/day
trinque: which is why I interact with it
through means
that do *not* block as it does
trinque: this is www born nonsense
that communication may only run one way, client can't listen for changes
mircea_popescu: go right ahead, produce a list of 5k rss items,
THEN dole
them out slowly.
trinque: yes, send me
the bursts as
they happen, don't render
the RSS each
time
mircea_popescu: asciilifeform
trilema ~delays~ rss, you udnerstasnd me ?
trinque: could get me a pg connection and I could listen for pg_notify on a
trigger of
that
table
trinque: only way
to deal with
the nonsense
that one "must" respond
to allcomers "now"
mircea_popescu: this is ~what
trinque said except his is more general.
mircea_popescu: a db write is either insert or update ; finding out
things is usually a select. it ~may~ be worthwhile
to separate your reads from
the writes, because it is
technically possible (thopugh i'd hope unlikely)
the db is dumb enough
to put write locks in for something like "update x on y" even
though it should be "select y if z
then update x".
trinque: doing all
this in
the request/response cycle will kill ya eventually
trinque: two
thoughts, beyond which a look at
the actual
thing would be needed. 1) queues and workers, always 2) db acts as your queue, schema reflects
the stages of work
mircea_popescu: table got marked crashed, so all you could load would be
the comments, sorta funny half-trilema
mircea_popescu: pretty sure you weren't able
to do it after i fucked it
mircea_popescu: these can
take minutes, and
the site isn't down during, at all.
mircea_popescu: asciilifeform no, i on occasion do multi-row updates. such as (lolz) recently when i made every entry of
the 50k items in article db read
the same
thing.
trinque: can even fire
the updates inside
the db with
triggers, so everything is
transactionally accurate