Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
ahachete
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
35 ms
·
361.
▲
by
ahachete
11y ago
I attended @marknadal's talk at Distributed Matters Berlin ( https://2015.distributed-matters.org/ber/speakers/#284925727... ). It promised a lot. After the talk, I was left with many unclear messages, lots of
362.
▲
by
ahachete
11y ago
An array is basically a set of homogeneous fields indexed by number, which are probably accessed in constant-time. A relational table is a completely different beast. Even after disregarding performance (which might be an abysmal difference
363.
▲
by
ahachete
11y ago
> I have to admit that I'm still not quite sure about arrays in relational databases. Don't get me wrong, I use them all the time, but it kinda feels like when you've got tables that you just know could be normalized more
364.
▲
by
ahachete
11y ago
To generate table diagrams that you can navigate (in HTML), SchemaSpy ( http://schemaspy.sourceforge.net/ ) is really good.
365.
▲
by
ahachete
11y ago
Pulling a document together back from its parts cannot be faster than jsonb or whatever. But it can be orders of magnitude faster if you are pulling a collection out of a query and you avoid scanning the whole thing. Let me elaborate. When
366.
▲
by
ahachete
11y ago
There are many reasons. The first is that Java is in our opinion the language with the biggest and greatest ecosystem of open source libraries on top of which we can build our software. And this is saving many man-years for us. I contrast,
367.
▲
by
ahachete
11y ago
Or use ToroDB ( http://www.torodb.com ) that speaks the MongoDB protocol but stores the data relationally, in PostgreSQL. Directly. No ETL, no mosql required :) (ToroDB developer here)
368.
▲
by
ahachete
11y ago
Hi, thanks for the reply! I will read the more detailed document. It would probably make more sense to me. From the description of MVCC that you say, it looks like you're storing the whole replicated state machine that you have via the
369.
▲
by
ahachete
11y ago
Thank you for sharing your strategy for concurrent transactions. It's a very interesting topic :) I see however some possible pain points in this strategy. My main concerns are: * This looks to me a lot like some poor (no pun intended)
370.
▲
by
ahachete
11y ago
Hmmmmmmm ok, good idea. Adding to our TODO list, hope to get it out soon ;P
371.
▲
by
ahachete
11y ago
In the PostgreSQL world, there are extensions ( http://www.postgresql.org/docs/9.4/static/extend-extensions.... ). Since extensions are self-contained groups of database objects (i.e., code), are versioned and
372.
▲
by
ahachete
11y ago
That would be awesome to have some numbers about this topic. Thanks for your interest. I guess with other systems like Paxos it could be solved by separating the notion of learners and acceptors, which are usually collapsed in the same node
373.
▲
by
ahachete
11y ago
Yes, I got that, maybe I wasn't clear enough. My main concern is that slow nodes (rather than failing nodes) may easily provoke latency spikes, and that seems to me a quite frequent situation. The good point about quorum writes is that
374.
▲
by
ahachete
11y ago
Very insightful post. My main concern with this approach is that having the ISR a fixed size (at any given time), as the post explains, it is subject to latency spikes if a node of the ISR is slow. This seems to me it would happen a lot in
375.
▲
by
ahachete
11y ago
> Anyone who has run a number of postgres replicas can tell you that their ability to recover from a network partition is directly proportionate to their wal_keep_segments value and there isn't otherwise much to it. Rather than wal
376.
▲
by
ahachete
11y ago
Well, PostgreSQL is not a distributed database. Sure, the study may have involved one of the HA solutions available for PostgreSQL, but it wouldn't have been a PostgreSQL study then. As some comment below, the reason for this observe
377.
▲
by
ahachete
11y ago
That's not precise. If you modify the package and distribute it to your users, they must have access to the source code (including the changes, which also become licensed under the same terms). Up to this point, it's the same as
378.
▲
by
ahachete
11y ago
If bug fixes take weeks to get to the CE, as one post below quoted from Couchbase's website, how is it possible that you say that the CE is probably fine? I'd rather say it's pretty useless. I wouldn't run anything where
379.
▲
by
ahachete
11y ago
Oh, please, my eyes hurt so much. Please, please, please change that "WHERE boolean_column IS FALSE" to "WHERE NOT boolean_column". Thank you ;P
380.
▲
by
ahachete
11y ago
Maybe without loss of relevancy, but maybe with data loss. That may be fine (or not). If you haven't done it yet, I'd recommend that you check Jepsen's analysis of ES: https://aphyr.com/posts/323-call-me-
381.
▲
by
ahachete
11y ago
Testing with a different database would only be good if you: a) Also test with your real production database b) You restrict yourself to using the lowest common feature denominator of both databases (which is probably a pretty low figure) S
382.
▲
by
ahachete
11y ago
Great job, craigkerstiens. I'm sure it needs more love and more content, but this is definitely a great start. PostgreSQL's documentation is outstanding, but at 3004 pages (9.4's full documentation PDF) is no piece of cake. T
383.
▲
by
ahachete
11y ago
I was thinking of a system where data is extracted from the source database and then the (changes) data are processed real-time by a software that consumes this stream. So other than the obvious differences (need to write the software, SQL
384.
▲
by
ahachete
11y ago
usman-m, the approach of PipelineDB seems really interesting. However, I'd like to understand how in your opinion it compares with processing the stream of data changes accessed over PostgreSQL's logical decoding ( http:/
385.
▲
by
ahachete
11y ago
There are many queries for which using an index is a worse query plan than running them with it. Indexes are not silver-bullet. Plus having queries to fail if not use an index... seems worse than just having slower (if that would be the c
386.
▲
by
ahachete
11y ago
How not having a query optimizer makes queries more predictable? It makes them slower for sure, but not more predictable. Indeed, I find NoSQL very unpredictable. When your query hits and index, the query goes well. When not, you usually en
387.
▲
by
ahachete
11y ago
Those derivatives are, apart from not being really SQL (but a SQLish-like in the best case), only target an incredibly small subset of what is SQL. When they say "we implement a subset of SQL" they really mean "we have a lang
388.
▲
by
ahachete
11y ago
There's no such concept of Storage Engines/Plugins in PostgreSQL. So it looks more unlikely this could happen in short time.
389.
▲
by
ahachete
11y ago
That is correct. However, only if there is effectively the API service in the middle, making your AGPL program internal. But if you are exposing an AGPL program (let's say a database) as-a-service, you cannot have an API service in bet
390.
▲
by
ahachete
11y ago
It's always nice to have a post explaining that you can comment in SQL. Most people are not aware of this, and it definitely helps when reading a DDL. I have to agree that sometimes there are superfluous comments that harm more than
More ›