We always had dots (or slashes) in zeros :) It came to us from ancient times when you could confuse "o" ("O") with zero. Some early teletypes began using the slashed zero to avoid confusion. Dots sometimes simulate the slash
Did you guys take part in Postgres survey they posted up on their website? That data helps them develop, so, do contribute to their survey questionnaires.
Small mistake in your query for postgres 17. You missed the id 4. You did a select ....... where id in (1, 2, 3, 5, 6, 7, 8, 9, 10) number 4 is missing. Whereas in postgres 16 you did have all 10 ids. I also noticed that even though the number of hits and idx scans in postgres 17 is much lower than 16, the planning time and execution time was higher? (And that was including the mistake above where the query in postgres 17 had 1 less item to find). That seemed a bit weird.
Bitmap heap scan is slower than Index only scan. That is the reason why planning took more time as it has to go through the array and see if the values are contigous and if they are not then index only scan would be removed from the query plan and changed to bitmap heap scan.
@@SudharshaunMugundan If you look at the final numbers after caching and stuff had happened. PG17: planning time => 0.129 ms, execution time => 0.145 ms. PG16: planning time => 0.133 ms, execution time => 0.096 ms. And keep in mind that PG16 has 1 extra ID to find compared to PG17. So PG17 might be more efficient when it comes to doing idx scans, but it seems that in terms of performance it is the same (or worse in some cases). But who knows. The example shown in this video isn't really a real world scenario since you will hardly have a table that exists of one column with autoincremented integer IDs. Maybe with other types of data PG17 is much faster.
since Postgres uses a heap and the data is not sorted, this means that to effectively use the new logic, you need to use the CLUSTER command more often, right?
Such an interesting topic completely butchered with a ridiculous presentation style. Which is a shame because @hnasr clearly would be able to do better.
I agree, it is a preference. I prefer grown men not behaving as if they're 12 just to fake some IMO unnecessary enthusiasm. So, you guys just go on enjoying the show, I'll switch the channel.
Database fundamentals course databases.win
We always had dots (or slashes) in zeros :)
It came to us from ancient times when you could confuse "o" ("O") with zero. Some early teletypes began using the slashed zero to avoid confusion.
Dots sometimes simulate the slash
Did you guys take part in Postgres survey they posted up on their website?
That data helps them develop, so, do contribute to their survey questionnaires.
15:47 good programming fonts have dots in zeroes to easily distinguish the letter O and the digit 0 from each other.
postgres is amazing!
Thank you for this video
Small mistake in your query for postgres 17. You missed the id 4. You did a select ....... where id in (1, 2, 3, 5, 6, 7, 8, 9, 10) number 4 is missing. Whereas in postgres 16 you did have all 10 ids.
I also noticed that even though the number of hits and idx scans in postgres 17 is much lower than 16, the planning time and execution time was higher? (And that was including the mistake above where the query in postgres 17 had 1 less item to find). That seemed a bit weird.
I think the planning time (and the strategy selected) were off precisely because of the typo in the query. Index scan would've been much faster.
Bitmap heap scan is slower than Index only scan. That is the reason why planning took more time as it has to go through the array and see if the values are contigous and if they are not then index only scan would be removed from the query plan and changed to bitmap heap scan.
@@SudharshaunMugundan The index only scan was also slower in PG17
@@SudharshaunMugundan If you look at the final numbers after caching and stuff had happened.
PG17: planning time => 0.129 ms, execution time => 0.145 ms.
PG16: planning time => 0.133 ms, execution time => 0.096 ms. And keep in mind that PG16 has 1 extra ID to find compared to PG17.
So PG17 might be more efficient when it comes to doing idx scans, but it seems that in terms of performance it is the same (or worse in some cases). But who knows. The example shown in this video isn't really a real world scenario since you will hardly have a table that exists of one column with autoincremented integer IDs. Maybe with other types of data PG17 is much faster.
You are very cool sir.❤
love me some optimisations
since Postgres uses a heap and the data is not sorted, this means that to effectively use the new logic, you need to use the CLUSTER command more often, right?
Can in be combined with prepared statements for dynamic length? So the planner does not get executed each time. Probably using the "any" function?
I noticed planning time for 17 is little higher than 16. can you explain this impact?
Mocking american accent from Hussein in the end is 🤌
no uuid v7 :(
Wondering why in PG17 the planning and execution times were longer? This doesn't seem like an improvement.
yeah I just noticed that too.
I installed pg17rc1 lets hope this isn’t a consistent problem in the final release.
It's because of the typo in the query (missing 4 in the query)
Incremental backups is huge I think! You just glossed over it :(
Music to my ears.. in clauses are much more human readable compared to exists
Imagine data is not sorted then
love your boozy demoes
Such an interesting topic completely butchered with a ridiculous presentation style. Which is a shame because @hnasr clearly would be able to do better.
what do you want him to do instead? Give feedback instead of just complain
I don't agree. I actually love his presentation style. Sometimes your preferences aren't universal and that's okay
I agree, it is a preference. I prefer grown men not behaving as if they're 12 just to fake some IMO unnecessary enthusiasm. So, you guys just go on enjoying the show, I'll switch the channel.
@@Vic-ky3cc so you prefer presenters who actually hide their enthusiasm?..
Maybe just read a book then.