magden

7 ms·

31.
by magden 3y ago
I don't think we need specialized databases for vectors. Relational databases can easily be expanded by vector data types and operations. They will eventually catch up by supporting what was once a unique feature of the new system: ht
32.
Sharded Doesn’t Imply Distributed(medium.com)
2 points by magden 3y ago|0 comments
33.
Is the DBEngine Database Ranking Fair?(medium.com)
3 points by magden 3y ago|0 comments
34.
Is Postgres rank screwed on DBEngines?(twitter.com)
2 points by magden 3y ago|0 comments
35.
by magden 3y ago
Nice, thanks for catching the issue! https://github.com/dmagda/pg-compute-node/issues/5 This extension is primaraly for those who avoid using database functions at all because of not-the-best dev experience.
36.
by magden 3y ago
Thank you for feedback. Sharing a bit more details to make things clearer. Upon a function invocation, PgCompute does the following: 1. Constructs a function signature (name + arguments) and checks if the function was invoked before. (there
37.
by magden 3y ago
PgCompute uses the plv8 extension on the database end. Basically, PgCompute will be transferring the function logic to the database where plv8 will get it executed. This function transfer happens only once and then PgCompute just passes the
38.
by magden 3y ago
Yeap, that was the main reason for building this client-side extension/module - so that we, developers, can execute the functions from the application source and our preferred IDEs.
39.
by magden 3y ago
Hey folks, I'm the one who created this extension. Looking forward to your feedback, thoughts and suggestions.
40.
PgCompute: New PostgreSQL Client-Side Extension for Database Functions(yugabyte.com)
39 points by magden 3y ago|10 comments
41.
by magden 3y ago
I bet that the `watch` feature would make to the list if the article was written these days. `watch` is the coolest Postgres feature that I've discovered recently.
42.
by magden 3y ago
It should be helpful for maintenance and DDL tasks. Such as I need to build a secondary index over a large table and do something once the index is ready. Start the index creation with pg_later, check the status later and do what you need t
43.
by magden 3y ago
Another reason why sharding is not always the best for use cases when you need to re-shard frequently. They should take a look at distributed Postgres dbs like Yugabyte.
44.
by magden 3y ago
When discussing GCP, the latency between AZs within the same region is approximately 5 ms. Thus, if you have a 3-node database cluster spanning 3 AZs (all within the same region), a transaction can be committed in the 5-10ms range using Raf
45.
by magden 3y ago
I can only concur that multi-region apps are becoming the new normal. Deploying app instances across distant locations was never an issue. However, databases used to be the bottleneck. I'm glad to see that changing, thanks to Cockroach
46.
My final take on Gradle (vs. Maven)(blog.frankel.ch)
3 points by magden 3y ago|0 comments
47.
by magden 3y ago
This is the right move for Scylla. Overall, looks similar to YugabyteDB that distirbutes data by sharding tables into tablets as well. The cluster monitors the cluster size (number of nodes) and the size of each tablet (data volume), and ad