211–220 of 220 posts
Earlier quoted context omitted.
I mean, they can - but they’re always wrapped up as pseudo-tables. Not everything is best described as a table, y’know?
> they’re always wrapped up as pseudo-tables. Are they??? Not as I understand it.
Earlier quoted context omitted.
> they’re always wrapped up as pseudo-tables. Are they??? Not as I understand it.
If you call “select 1;”, you get back a table with 1 row and 1 column.
select * from orders where custno = (select custno from customers where name = 'John Doe');
select * from orders where custno = 123456; -- John Doe's customer number
So I don't really see what the big problem is either way. Hoping I'm not being stupid AF, maybe you could explain further?
Earlier quoted context omitted.
I'll probably come across as a shill here, but there is a lot going on with SQL Server, all included in your license (Standard Edition has limitations on scaling). Some of these things are merely passable, some are great, but it's all included. The key takeaway is that SQL Server is a full data platform, not just an RDBMS. - RDBMS: very solid, competitive in features - In-memory OLTP: (really a marketing name for a w…
Yes, it has a ton going on but most of companies I've found using it are using primarily as RDBMS and thus MySQL/Postgres could replace it. Other stuff it did could be replaced by tools more geared towards specific function and most of time, at much lower cost. Licensing isn't cheap. For anyone wondering, before discount, it's 876/yr per core for Standard and 3288/yr per core for Enterprise. Also note that Standard i…
I’d also note that most orgs and use cases probably don’t need more than 24 cores and 128GB RAM.
I think for an organization that wants a near-trivial out of the box experience with RDBMS, reporting, and analytics, Standard Edition is not a bad deal. Especially for the many organizations that are already using Microsoft as their identity provider and productivity suite.
Earlier quoted context omitted.
If you call “select 1;”, you get back a table with 1 row and 1 column.
That's just because SQL clients present their results that way, AFAICS. If you use a sub-query like in, say, select * from orders where custno = (select custno from customers where name = 'John Doe'); you'll get the same result as if you'd put that scalar in your query, like select * from orders where custno = 123456; -- John Doe's customer number Or maybe you're right, that to SQL databases scalar values are single-…
Imagine the programming language equivalent. We could make a programming language where every function call returns a table. If you expect 1 return value from your function, the caller grabs the first row out of the return array, and the first column out of that row. It would absolutely work, and that its mathematically equivalent in some sense. But it would be confusing, computationally inefficient and error prone. What happens if there's more than 1 row in the table? Or more than 1 column? What happens if the type of the columns doesn't match match what you expect? What happens if the table is empty? Or you want a function which returns a two lists instead of one? We could write that programming language. But it would be pretty weird and frustrating to use.
This is the situation today with SQL. Every query returns a dynamically typed table. Its up to the caller to parse that table.
With redis, the caller expresses to the database what kind of value they expect in the query function name. (At least, list or scalar). The database guarantees that a GET request always returns a scalar value, and LRANGE always returns a list. I think this has better ergonomics because the types are more explicit.
The article mentions Greenplum, but it's worth noting that when the code was closed, several of the original developers created an open-source fork, Cloudberry, which seems to be thriving. Cloudberry was accepted into the Apache project this year, and has synced with Postgres 14, whereas the closed-source Greenplum is still stuck on Postgres 12. The architecture is quite ancient at this point, but I'm not sure it's c…
This is mostly correct, but it's worth mentioning that cloudberry substantially predates Greenplum going closed source. It just got quite a boost from that change happening. Different dev team too, afaik none of the original Greenplum team was involved with Cloudberry until very recently. Also, Greenplum 7 tracks postgres 14. Which is still old at this point, but not so bad as 12.... I also don't think I'd call the a…
Earlier quoted context omitted.
Thanks for the context. In what way would you say Cloudberry lags behind Greenplum technology-wise? I see newer Greenplum versions have a lot of planner improvements. Greenplum 7 is listed as tracking Postgres 12 in the release announcement [1], and the release notes for later 7.x versions don't mention anything. Is there a newer release with higher compatibility? When I say ancient, I mean that it's a "classical" sh…
Cloudberry, last I checked, took their snapshot of all the Greenplum utilities way before the repos got archived and development went private. The backup/restore, DR, Upgrade, and other such seem to leave a lot on the table. I haven't checked in a bit, it's possible they've picked back up some of that progress. You're completely right, I had the wrong PG version in my memory. Embarrassing, thanks for catching that.
Here is the unofficial roadmap of Cloudberry:
1. Continuously upgrading the PostgreSQL core version, maintaining compatibility with Greenplum Database, and strengthening the product's stability. 2. End-to-end performance optimization to support near real-time analytics, including streaming ingestion, vectorized batch processing, JIT compilation, incremental materialized views, PAX storage format, etc. 3. Supporting lakehouse applications by fully integrating open data lake table formats represented by Apache Iceberg, Hudi, and Delta Lake. 4. Gradually transforming Cloudberry Database into a data foundation supporting AI/ML applications, based on Directory Table, pgvector, and PostgresML.