I'm still confused how people prefer oracle [1] other postgres.
I used to call it CrashGreSlow back when Mysql was maintained. Postgres had a manifesto which trash-talked Oracle but it was not a reliable product at that time. Maybe the people who said it was fast were running it on ram disks with fsync turned off or something.
After mysql got bought by Sun and put on ice, postgres caught up with the hype and now it is pretty reliable. That wasn't always the case.
It is never just PostgreSQL is a great database. It’s always that MySQL, Oracle, MongoDB and the hundreds of NoSQL databases are all unusable junk with no unique benefits.
MongoDB is crap.
I think the people who use Arangodb don't talk about it because they see it as a competitive advantage.
Right now I am working on an abstraction layer for document databases and using couchdb side by side with Arangodb. I guess I'll have to write a N1QL parser to go with my AQL parser.
The database I have the most fun with is SQLite. It is single-user, which means you can't log in with the SQL monitor when your program is running, but if you can accept that it's just great.
However the fact that it's owned by Oracle does make it a little bit scary, even though we have no exposure to their code or anything linked at all. I sort of wish we'd chosen Postgres instead.
Oracle has been a reasonable steward of mysql. They started making releases again. They haven't really moved it forward but I am sure they are taking care of their customers.
So far I haven't been impressed with mariadb and the other forks. For instance I would download it because I heard some hype but the installer didn't work.
This simply is not true. I personally know a bunch of engineers who worked for MySQL AB and stayed on through the Sun and then Oracle acquisitions, and worked on MySQL that entire time.
Additional source: Sun acquired MySQL AB in early 2008. MySQL 5.1 was released in late 2008, and major releases continued on a cadence of every 2 to 2.5 years to this day. You can verify this via release notes, or via Wikipedia, among other sources.
> They haven't really moved it forward
This is purely a matter of opinion. From my own perspective, as someone who has been using MySQL for 15 years, I see substantial ongoing improvement in each major release.
If MySQL was as stagnant as you claim, why would the majority of the largest internet properties continue to rely on it as their primary data store?
Recent major versions have provided substantial enhancements to performance, replication, JSON/document support, and observability, to name just a few.
LISP difference(LISP x,LISP y)
{if NFLONUMP(x) err("wta(1st) to difference",x);
if NULLP(y)
return(flocons(-FLONM(x)));
else
{if NFLONUMP(y) err("wta(2nd) to difference",y);
return(flocons(FLONM(x) - FLONM(y)));}}
Of course, that's a Scheme interpreter, so it might be at least a little expected.
https://github.com/postgres/postgres/blob/master/src/backend...
Mind you, I'm biased because I've written a fair amount of actual "Lisp style C", e.g.:
http://www.kylheku.com/cgit/txr/tree/regex.c?id=2938a0d7e64e...
My detector for "this C is Lispy" has a rather high threshold / low gain.
You can still see the Lisp heritage in a few places, but overall I wouldn't say Postgres is "literally lisp in C".
In code that truly embraces "Lispy" lists, you cannot switch to an encapsulated list representation without making substantial changes to the code. For instance if you have any cdr recursion going on, that will have to be restructured, because a bag-style list doesn't have a cdr that is itself a bag-style list. (Perhaps the function has to be split into an external one that takes the List and then a local recursive part that works with the ListCell.)
I would say that to a fair extent, it looks to me as if the code anticipated a future retargeting to a different list representation, whereas the "Lispy" approach is to embrace a particular list representation.
Lisp programs sometimes need to improve the performance of adding to the tail of a list; it's done with some wrapping, like a structure that keeps a pointer to the tail. Usually that is only locally used; it doesn't "travel" as part of the representation of the list. It is not an encapsulation device, but only a process device. Of course there is also the common pattern of building up a list in reverse followed by a destructive nreverse. And the meta-approach of designing things to avoid doing work at the tail end of the list.
I just remembered the existence of some C code that has nothing to do with any Lisp implementation internals, which pushes and nreverses: http://www.kylheku.com/cgit/c-snippets/tree/autotab.c#n228
A double-ended queue (deque) can be formed in Lisp by using a pair of lists. So both ends of the queue are list heads, from which we cdr into the interior. I developed such a thing which is hosted here:
http://www.kylheku.com/cgit/lisp-snippets/tree/deque.lisp
With this deque, we simply use the push macro to add items to either end of the queue. pop-deque will remove an item from either end. Underflows are handled by rebalancing the dequeue: shuffling items from one list to the other. The cost of that is amortized. (BTW I see that pop-deque has a multiple-evaluation-of-arguments problem; it really should be written using get-setf-expansion.)
I think changing the list representation made sense in part because the rest of the codebase didn't use lists in a deeply Lispy way, for the most part.
That said, one can often capture much of the performance benefit with Postgres indexes - basically, instead of trying to tightly-pack the base tables, copy the data into indexes which are tightly packed exactly as you need. Put another way, Postgres indexes are synchronously updated materialized views - and yes, the Postgres planner/optimizer will automatically answer queries from an index if it's faster and all the columns are in there.
I esp recommend reading about function and expression indexes, as well as the (new) covering indexes.
http://blog.scoutapp.com/articles/2016/05/31/3-postgresql-in... https://www.endpoint.com/blog/2013/06/10/postgresql-function... https://paquier.xyz/postgresql-2/postgres-11-covering-indexe...
Better space usage and performance for that single index since the table is the index, slightly worse performance for non clustered indexes due to a double index traversal.
FWIW I much prefer Postgres to Oracle, but not because of the technology as much as the price.
Postgress makes a copy of _every_ row and you need 100GB of extra space on the hard-drive until you commit the transaction. Now extrapolate to a 1TB table that needs updating.
Oracle has a way of doing this w/o copying the entire row.
This only happens if the column is indexed, heap-only-tuples will allow in-place updates otherwise. This doesn't dismiss it as a potential problem entirely, but depending on your needs you may never run into this.
That's what the zHeap storage engine for Postgres fixes - in-place updates for fixed width data.
And I have seen Oracle 12c servers completely lock because of that way.