SQL IN clauses are miles faster in Postgres 17

[@hnasr]

Database fundamentals course databases.win

[@abc_cba]

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.

[@Voidstroyer]

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.

[@hkupty]

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.

[@raghavamorusupalli7557]

Thank you for this video

[@Yash-hn6ch]

postgres is amazing!

[@mrrolandlawrence]

love me some optimisations

[@banksy215]

Wondering why in PG17 the planning and execution times were longer? This doesn't seem like an improvement.

[@hnasr]

yeah I just noticed that too. I installed pg17rc1 lets hope this isn’t a consistent problem in the final release.

[@hkupty]

It's because of the typo in the query (missing 4 in the query)

[@ivinsergey7497]

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

[@iaminterestedineverything]

Music to my ears.. in clauses are much more human readable compared to exists

[@romansemkin3317]

Now I forgot what was in the video. I was thinking about the dots 😂

[@trymoto]

Mocking american accent from Hussein in the end is 🤌