I recently created a database engine (exosql [1]), only query and no storage. It uses postgres-like foreign data wrappers to get all data. It's not valid for big datasets, as it stores all in memory (or maybe it is?), but as a learning experience has been amazing to think and develop a real database: planner, executor, choose algorithms, implement features as lateral joins and so on. I will definetly listen very care…
How SQL Database Engines Work, by the Creator of SQLite (2008) [video]
31–40 of 134 posts
Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]
#32Any video filter experts here? Request to any video filter expert ------------------------------------ I started watching this. The slides are unreadable but the camera is perfectly still and the slides are for several "key frames" where the compression algorithm decides to replace one set of compression artifacts for another. For example try to read the first keyword under "Translates into:": https://www.youtube.com…
Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]
#33I don't like to use SQL engine because I don't understand how they work, I never really know if my query will be O(1), O(log(n)), O(n), etc, or what kind of algorithm will optimize my query. Who really does understand how a SQL engine work? Don't you usually require to understand how something work before starting using it? Which SQL analyst or DB architect really knows about the internals of a SQL engine? Do they kn…
You're not scared, you're just too lazy to learn the tools of your trade. Databases are not very complex and use pretty much only textbook data structures and algorithms. Understanding how they process a given query and how a query will probably perform/scale (even without EXPLAIN ANALYZE) is not hard to learn. You do need to learn it (at some point; you don't for small data, which is most). But it's far from difficu…
skeptical expression
Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]
#34I recently created a database engine (exosql [1]), only query and no storage. It uses postgres-like foreign data wrappers to get all data. It's not valid for big datasets, as it stores all in memory (or maybe it is?), but as a learning experience has been amazing to think and develop a real database: planner, executor, choose algorithms, implement features as lateral joins and so on. I will definetly listen very care…
Any books/lectures/articles you followed?
Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]
#35Earlier quoted context omitted.
How do you prefer to persist your data?
In memory database, dumped to file? Not saying how I would do it, just thinking alternatives. I’m using postgresql usually
If less frequently used parts of it don't fit, offload to disk.
Ideally, the DB should guarantee data integrity after a crash even if the DB is served from RAM.
That's the ideal scenario: You have the best of all worlds.
Coincidentally, that's exactly what Postgres does.
On top of that, it's the best NoSQL database currently available.
Of course, you can use it with SQL if you ever feel the need.
Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]
#36I don't like to use SQL engine because I don't understand how they work, I never really know if my query will be O(1), O(log(n)), O(n), etc, or what kind of algorithm will optimize my query. Who really does understand how a SQL engine work? Don't you usually require to understand how something work before starting using it? Which SQL analyst or DB architect really knows about the internals of a SQL engine? Do they kn…
Unless your data requirements are very specific, mem only, or not adapted to the relational paradigm any SQL engine will provide you with the best and more efficient algorithms to manipulate your data in the most common situations.
I think that if any, databases should be used more.
Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]
#37Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]
#38What is that acronym he keeps saying? MBCC?
Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]
#39Any video filter experts here? Request to any video filter expert ------------------------------------ I started watching this. The slides are unreadable but the camera is perfectly still and the slides are for several "key frames" where the compression algorithm decides to replace one set of compression artifacts for another. For example try to read the first keyword under "Translates into:": https://www.youtube.com…
How precious that you think someone cares.
Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]
#40Earlier quoted context omitted.
For Postgres at least, you can literally ask it how a query works, via EXPLAIN. Now, there’s a skill to understanding the output of that, but at least it isn’t a black box.
And the query plan can literally change out from under you at any time. SQL sucks. You should be able to dictate the query plan to the engine directly. If SQL exists as a tool to create and serialize such plans via exploration and experimentation, that’s fine. As a runtime query system it is completely unsuitable.