refset

19 ms·

1. 301.▲
   by refset 3y ago

   > defining the rules of suduko [...] in SQL Two rather distinct solutions: https://www.sqlite.org/lang_with.html#outlandish_recursive_q... http://conway.rutgers.edu/~ccshan/wiki/blog/posts&
2. 302.▲
   by refset 3y ago

   A shame indeed, they were only a few decades too early! The support for "Time Varying Data" gets discussed briefly in this 1995 paper by Stonebraker "The Design of Postgres" > POSTQUEL allows users to save and query h
3. 303.▲
   by refset 3y ago

   Expanding on the the above, > The original version of PostgreSQL from the 1980s did not remove dead tuples. The idea was that keeping all the older versions allowed applications to execute “time-travel” queries to examine the database at
4. 304.▲
   by refset 3y ago

   > there is an unsolved elephant in the room: It doesn't cover schema changes. 100% agreed. It's remarkable how Datomic also arrived on the scene in the same era (2012) but actually managed to solve a lot of these hard issues of
5. 305.▲
   by refset 3y ago

   Thanks for clarifying. > Compacted topics are typically not used in high-throughput workloads TIL, but it makes sense. Compaction/retention policies certainly introduce a lot of extra tradeoffs dimensions.
6. 306.▲
   by refset 3y ago

   Temporal tables, most likely. Although even SQL Server only supports system time versioning, not full bitemporal tables (as per the spec).
7. 307.▲
   by refset 3y ago

   This is a really interesting design - kudos. > Compacting the data may sound expensive, but in practice it's highly efficient since it only needs to happen once Is there any handling for tombstone records?
8. 308.▲
   by refset 3y ago

   Almost certainly https://prezi.com/
9. 309.▲
   by refset 3y ago

   I'm extremely keen to see what the SQL<->Elm experience might be (assuming something like that is part of the deal too). Simplifying how we interact with databases is arguably even more important/$valuable than simplifying U
10. 310.▲
    by refset 3y ago

    Fwiw my colleague is the author of https://github.com/wotbrew/relic and he started working on Incremental View Maintenance ~purely because he wants to build a simpler rogue-like :)
11. 311.▲
    by refset 3y ago

    Very true, although the digital-ness of computers isn't holding anything back at this point, now that storage is ~infinite and the virtues of immutability are widely recognised.
12. 312.▲
    by refset 3y ago

    I have been reading The Dream Machine by Waldrop recently (great book!) that discusses Bush's pivotal role in the development of computing...which has a remarkable irony: > Doggedly, and without success, [Bush] kept on trying to com
13. 313.▲
    by refset 3y ago

    The linked sibling post on "New Truffle and GraalVM Languages release" feels rather exciting too https://medium.com/graalvm/new-truffle-and-graalvm-languages... Specifically: > GraalVM language runtimes (f
14. 314.▲
    A Primer on Logic Programming(juxt.pro)

    117 points by refset 3y ago|7 comments
15. 315.▲
    by refset 3y ago

    Okay so on the Postgres question this mailing list thread is interesting: https://www.postgresql.org/message-id/8181205c-69e5-bde7-15e... I am no expert on Postgres but the thread seems to suggest the default out-of-th
16. 316.▲
    by refset 3y ago

    > Isn't Arrow biased towards analytics workloads? Like sibling commenter brings up, I'm not sure what that brings to the table for OLTP. That's right, I was thinking more about the network effects, not performance - see my
17. 317.▲
    by refset 3y ago

    I agree Arrow by itself doesn't address any novel/fundamental OLTP challenges, but I'm not arguing that the thing which eventually supplants Postgres will succeed because of best-in-class OLTP performance - anyone needing tha
18. 318.▲
    by refset 3y ago

    > it's a bit difficult to wrap my mind around how Arrow will help in distributed systems Comparing with the role of Protobuf is perhaps easiest, there's a good FAQ entry [0] which concludes: "Arrow and Protobuf complement
19. 319.▲
    by refset 3y ago

    I meant that mostly in jest, but in reality the pace of both database research and commercial development is happening faster than ever, so an explanation of "How Query Engines Work" is a moving target. Join algorithms and join pl
20. 320.▲
    by refset 3y ago

    Another Postgres-based project in this vein that makes use of Apache Arrow: https://heterodb.github.io/pg-strom/ > PG-Strom is an extension module of PostgreSQL designed for version 11 or later. By utilization of GP
21. 321.▲
    by refset 3y ago

    Polyglot means not having to fight with marshaling overheads when integrating bespoke compute functions into SQL, or when producing input to / consuming the output from queries. This could radically change the way in which non-expert p
22. 322.▲
    by refset 3y ago

    > KQuery does not yet implement the join operator. Whilst I applaud this book writing initiative, completing it could easily become a lifetime's work! It will be a fascinating journey to follow along with in any case. Apache Arrow c
23. 323.▲
    by refset 3y ago

    > How can I import `tsv` and/or n-triplets file into v2 XTDB so I can run a couple of queries on WatDiv ? I can't offer easy instructions for that right now as we've not adapted the benchmark for the 2.x branch yet (and I
24. 324.▲
    by refset 3y ago

    Firstly, disclosure: I work on XTDB, where we are in the process of building out a new columnar SQL engine that also (still) supports edn-flavoured Datalog, see https://xtdb.com/v2 Perhaps the most fundamental aspect here i
25. 325.▲
    by refset 3y ago

    Thanks :) The surprises don't stop though - it's abstract turtles all the way down...meaning plenty of fat to trim between UPDATE and what's happening in the MOSFETs. Might be of interest: https://arxiv.org/pd
26. 326.▲
    by refset 3y ago

    CRDT synthesis feels like a promising direction, e.g. see "Katara: Synthesizing CRDTs with Verified Lifting"/ https://arxiv.org/abs/2205.12425 / previous discussion https://news.ycombinat
27. 327.▲
    by refset 3y ago

    In a similar vein, this was news to me recently: > here’s a chart comparing the throughputs of typical memory, I/O and networking technologies used in servers in 2020 against those technologies in 2023 > Everything got faster, bu
28. 328.▲
    by refset 3y ago

    Thanks for sharing that - TIL! These blog posts elaborate with more detail: https://www.cockroachlabs.com/blog/vectorized-hash-joiner/ https://www.cockroachlabs.com/blog/vectorizing-the-merge-
29. 329.▲
    by refset 3y ago

    It's perhaps also worth a mention that embracing the internal characteristics of SSD throughout the software stack looks like the inevitable direction we're headed (short of another major breakthrough in storage tech) - e.g. see &
30. 330.▲
    by refset 3y ago

    Direct block storage is good, but note that SSDs are essentially just doing CoW internally too.