Live data from Hacker News

How SQL Database Engines Work, by the Creator of SQLite (2008) [video]

youtube.com

61–70 of 134 posts

Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]

#61

Earlier quoted context omitted.

SQL is a declarative language: You describe what you want , not how to get it. If that's not what you need, there are plenty of procedural languages whith which you describe how to get things . A query plan will change based on statistics. It's the engine's job to decide if your query is best served by parallelizing it to multiple cores, or deciding if it's worth JITing it before execution. The actual execution of th…

"You describe what you want, not how to get it." The entire archive of the pgsql users' mailing list disagrees. Every wants to know why their plan is suboptimal, or why it changed. People also want to know why the planner takes 100ms to generate the plan and only 1ms to execute the query, and so forth. The idea that you just say what you want and you get the optimal result from your database is just ridiculous to any…

The thing is, 99.999999% of the time (and I'm probably missing a few 9's) the engine does exactly the most optimal thing.

However, database engines aren't perfect -- I know I've encountered bugs in older SQL server versions where the query never finishes but making some trivial adjustments fixes it. This is a bug. And most mailing lists are filled with people encountering bugs. Saying what you want and getting the best result is exactly what you should expect.

Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]

#62

Earlier quoted context omitted.

SQL is a declarative language: You describe what you want , not how to get it. If that's not what you need, there are plenty of procedural languages whith which you describe how to get things . A query plan will change based on statistics. It's the engine's job to decide if your query is best served by parallelizing it to multiple cores, or deciding if it's worth JITing it before execution. The actual execution of th…

"You describe what you want, not how to get it." The entire archive of the pgsql users' mailing list disagrees. Every wants to know why their plan is suboptimal, or why it changed. People also want to know why the planner takes 100ms to generate the plan and only 1ms to execute the query, and so forth. The idea that you just say what you want and you get the optimal result from your database is just ridiculous to any…

> Every wants

This seems like mere selection bias.

As the sibling comment points out, users who have no problem aren't likely to post "Everything is fine!" to the mailing list. In fact, it would likely be rude to do so.

Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]

#63
post #26
post #6

I 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…

I really wonder who, today, have data that cannot fit in RAM, apart from big actors. It's also a question of price. Once you get above about 256 GB of RAM server prices start to go up really really fast. And while there are systems with dozens of TB of RAM they are stupidly expensive. So even if, in theory, most databases could fit in RAM, most people cannot afford that. And at the end of the day, 100+TB isn't that l…

> Once you get above about 256 GB of RAM

I think it might be as high as 1TB these days, though with what's going on with DDR4 prices, the situation is strange at the moment.

Of course, I don't disput your point that a 100+TB database isn't all that large, especially with indexes.

I suspect that it's this false dichotomy of "fit in RAM" and "big data" has resulted in many needless forays into distributed computing.

Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]

#64

Any 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…

I'm sorry you got downvoted for this comment. HN voting is the worst.

Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]

#65
post #59
post #51

so I was trying to figure out why a query was slow the other day... it was a nasty query with like 14 joins... I used explain and saw that it was a mess... now in my case I was able to switch to outer joints and nest related joins and got it fast.. but I had some interesting thoughts. In SQL, indexes are implicit.. they are used if available but it's easy get a large query to scan sometimes when it shouldnt... what i…

Two reasons to not have indexes in the query: 1. Query expresses the result it produces, not the method that was used to obtain it. Semantic vs implementation. It may be a pain to write, but it will be easier to read later. 2. DBA could add/drop indexes on the fly to tune performance of a live system without making any changes to the application code. And being 100% certain he is not changing the semantics of what's…

So, the way I think this should work is that there should be a way of addressing the table sources in a query from an application that has them parsed, and then externally (i.e., in the application) provide planning hints to the compiler.

Something like (in some terrible pseudocode):

    q = parse_query("...");
    q.hint(FIRST_TABLE, "a");
    q.hint(INDEX, "b", "b_idx1");
    c = q.compile();
    r = c.run(...);

Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]

#66

Earlier quoted context omitted.

SQL is a declarative language: You describe what you want , not how to get it. If that's not what you need, there are plenty of procedural languages whith which you describe how to get things . A query plan will change based on statistics. It's the engine's job to decide if your query is best served by parallelizing it to multiple cores, or deciding if it's worth JITing it before execution. The actual execution of th…

"You describe what you want, not how to get it." The entire archive of the pgsql users' mailing list disagrees. Every wants to know why their plan is suboptimal, or why it changed. People also want to know why the planner takes 100ms to generate the plan and only 1ms to execute the query, and so forth. The idea that you just say what you want and you get the optimal result from your database is just ridiculous to any…

> The entire archive of the pgsql users' mailing list disagrees. Every wants to know why their plan is suboptimal, or why it changed.

And rather a lot of the archives of $scripting_language_of_your_choice are people confused about duck-typing/type system failures. That doesn't mean scripting languages should be replaced with statically typed ones; just that there are pain points in every system, and right (or wrong) tools for every job.

Don't believe me? Check how much of the FAQ traffic from first-time Rustaceans (or Swift/Java/etc. newcomers) has to do with how to satisfy their language's type system.

You pick your poison. SQL gives you a clearly defined set of tradeoffs up front. If that's not for you, no worries, move along.

Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]

#67

Earlier quoted context omitted.

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…

>Databases are not very complex and use pretty much only textbook data structures and algorithms skeptical expression

"________ is not very complex and uses pretty much only textbook data structures and algorithms" is pretty much a false statement for any engineered product.

Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]

#68
I'm not going to call anyone out here, but why do people keep using the word orthogonal?

It doesn't even compute. It doesn't even make any sense, in how they use it in relation to the topic.

Are the issues at right angles of one another? No.

Are the issues statistically independent of one another? Perhaps.

I suggest to use a more appropriate descriptive word to describe the situation.

You folks should read the urban meaning of orthogonal, to understand how people roll their eyes at you, when you inappropriately use the term.

https://www.urbandictionary.com/define.php?term=orthogonal

Just another friendly PSA.

Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]

#69
post #10
post #6

I 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…

Your concern about the opaque and abstract layers below you apply to language compilers as well (which I think is the "better" alternative you seem to prefer). There is literature legion on the implementation of the database that would assuage you, should you concern yourself with reading it. I don't think you need to. Trust that many many smart people have engineered many many decades of excellent software. That is,…

> There is literature legion on the implementation of the database that would assuage you, should you concern yourself with reading it. I don't think you need to. Trust that many many smart people have engineered many many decades of excellent software.

can you recommend some material?

Re: How SQL Database Engines Work, by the Creator of SQLite (2008) [video]

#70

I'm not going to call anyone out here, but why do people keep using the word orthogonal? It doesn't even compute. It doesn't even make any sense, in how they use it in relation to the topic. Are the issues at right angles of one another? No. Are the issues statistically independent of one another? Perhaps. I suggest to use a more appropriate descriptive word to describe the situation. You folks should read the urban…

That's how languages evolve. Words that meant one very distinct thing come to mean something only partially like the original. People decry the misuse. And finally the new meaning becomes the one true meaning and the original sense is marked in dictionaries as "archaic."

For a word that's gone through that exact cycle, have a stare at "artificial," which was the adjective for "artifice," which at one time meant craftsmanship. When St. Paul's Cathedral was first shown to King Charles II, he praised it for being "very artificial" -- a compliment. [1]

In the meantime, I agree that it can be frustrating to see words apparently misused. But I think this is hardly the mark of an "idiot," as you put it.

[1] https://quoteinvestigator.com/2012/10/31/st-pauls-cathedral/

Post reply on HN