Viewing profile — abadid
abadid
HN member- Joined
- Thu, Apr 06, 2017, 6:04 PM UTC
- HN karma
- 148
- Public activity
- 70 items
- HN profile
- View on Hacker News ↗
About abadid
No profile information was provided.
Recent public activity
-
comment
Comment #48804735
The hype doesn't always live up to reality.
- story
-
comment
Comment #46775743
More proof that it is really slow to access data in a database over JDBC.
- story
-
comment
Comment #44987086
Short summary: Trino uses JDBC in ways in which it was not designed and this can result in massive performance bottlenecks. Sometimes partitioning source data can mitigate the bott…
- story
-
comment
Comment #44573983
A lot of people don't realize how slow it is to access data in bulk from a database using JDBC. JDBC was never designed for the use case that Trino uses it for.
- story
-
comment
Comment #42628797
This article summarizes research from my lab in collaboration with ByteDance published in CIDR (a computer science conference held in Amsterdam two weeks from now) on a new columna…
- story
-
comment
Comment #42472521
Why use PostgreSQL instead of columnar databases that are likely to perform way better for these types of analytical workloads?
-
comment
Comment #29269554
I agree that in theory they could both co-exist for the reasons you state, but in practice I think it's unlikely a company that invests in a data fabric (which is largely a technol…
-
comment
Comment #26581849
In general, whenever you need to perform a join (of multiple datasets), that ends the pipeline of local operations on a partition. Other operators as well that necessarily require …
-
comment
Comment #26581326
I'm the author of this piece. I'm happy to respond to comments in this thread.
-
comment
Comment #25377785
IMO, it's hard to put a price on strong isolation and consistency. Being able to write an app that that uses atomic transactions, that are isolated from concurrently running transa…
-
comment
Comment #21192169
See what I wrote below regarding Spanner. The same thing applies to the CockroachDB solution. If you run 2PC for multi-region transactions that is very slow (increases latency), an…
-
comment
Comment #21185218
Yes --- the post explicitly states that deterministic execution is a prerequisite. SLOG is CP from CAP, so indeed suffers from unavailability in the event of a network partition.
-
comment
Comment #21183934
Let's say you have a transaction that writes data located in different quorums atomically. This is called a "multi-home" transaction in SLOG. Most of the machinery in the paper is …
-
comment
Comment #21183870
Latency is measured from the client. In the example in the post (and more details in the paper), you see the latency tail from when clients access data that is far from them. The c…
-
comment
Comment #19820934
As mentioned in the post: "There are several ways to achieve [serializability] — such as via locking, validation, or multi-versioning." Deadlock happens under some, but not all imp…
-
comment
Comment #19818645
Glad to see to see this post on HN. I'm the author and happy to respond to questions in this thread.
-
comment
Comment #19028848
Please see: http://www.cs.umd.edu/~abadi/papers/determinism-vldb10.pdf
-
comment
Comment #19010005
magicalhippo asked a similar question both with regard to complexity and garbage collection. I think it is best to combine these threads, so please see my response there ... https:…
-
comment
Comment #19009978
Every transaction has an numeric identifier. These identifiers are used to order versions of updates to a data item. Versions from higher transaction IDs are considered to be "afte…
-
comment
Comment #19009961
It is one coordinator per transaction. As far as coordinator robustness, I discussed this in the following paragraph from my post: "There are two categories of work-arounds to the …