Jean-François Gagné
jfg956.bsky.social
Jean-François Gagné
@jfg956.bsky.social
System / Infrastructure Engineer and MySQL Expert, blogger, tech. speaker, cyclist, runner, scuba-diver instructor, Québécois, French, and Canadian.
Montréal Area, Québec, Canada
https://linktr.ee/jfg.mysql
So for a week, time offset are not the usual one (5 hours instead of 6 between Montréal and Paris). 3 of 3
October 26, 2025 at 9:13 PM
Europe set their clock back (get off Summer Time) on the last Sunday of October (today, October 26), and North America gets off Daylight Saving Time on Sunday November 2nd. 2 of 3
October 26, 2025 at 9:13 PM
Thanks for posting about this. I forgot Europe was changing time this weekend. North America is next weekend, so we have different time delta for a week.
October 26, 2025 at 9:04 PM
Is there a matching blog post ? Much quicker to skim than a video.

Also, may I suggest to put a few SQL statements in the description on Youtube ? This makes testing easier, and can be a TL&DR.
September 24, 2025 at 12:31 PM
It could also have been a mine field.
June 6, 2025 at 2:02 AM
Or it is property of the mine.
June 5, 2025 at 9:31 PM
Another thing...

> it means doing 2-3 rountrips to the database instead of just one

This reminds me of something I should have done some times ago, now done, see link below.
bugs.mysql.com/bug.php?id=1...
MySQL Bugs: #117903: Please consider allowing preparing and executing - and maybe closing - a statement in a single round-trip.
bugs.mysql.com
April 7, 2025 at 6:28 PM
Another complexity is memory consumption accounting, which would not only be at the connection level, but also at the global level. There are also solutions of this, but I am not sure the increased complexity would be worth it. 7 of 7
April 7, 2025 at 6:03 PM
One such complexity would be to know when a global prepared statement can be released, but this is mostly a solved problem with reference counters. 6 of N
April 7, 2025 at 6:03 PM
However, it does not mean that prepared statements need to be managed at the connection level by the database server, they could be managed at the global level. This would optimize memory usage, but at the cost of implementation and runtime complexities. 5 of N
April 7, 2025 at 6:02 PM
So IMHO, there are real and hard obstacles to the implementation of global-scoped prepared statements, and it might be more simple to keep them session-scoped. 4 of N
April 7, 2025 at 6:02 PM
Generalizing the previous problem, global-scoped prepared statements would break in situations were the application is connecting to a "distributed database", including to a multi-writer cluster (MySQL Group Replication as an example). 3 of N
April 7, 2025 at 6:02 PM
One such situation is when the application is connecting to a pool of read replicas: the prepared statement might exist on one replica, but not on the others. 2 of N
April 7, 2025 at 6:02 PM
I would like to react to "one major annoyance is that these statement_id are session-scoped". Global-scoped Prepared Statements might look appealing, but it can also be "more complicated" in some situations. 1 of N
April 7, 2025 at 6:02 PM
I am quite sure we would welcome you North. I am half joking, but also half serious. Have you considered it ?
March 20, 2025 at 2:42 PM