Safely Dropping MySQL Tables

Re:Safely Dropping MySQL Tables by daenz on Monday July 25, 2022 @04:22PM (#32230406)

I didn't upvote it, but I think the product does inspire discussion about why we don't have basic important features like mandatory "last accessed" metadata on external state sources. Think of the number of hours of pain due to someone being "sure" a database/api/resource wasn't used, and then removing it. I'm not really put off by the advert for that reason.

[ Parent | on HN ]

Re:Safely Dropping MySQL Tables by throwusawayus on Monday July 25, 2022 @04:47PM (#32230689)

tracking access time (every read) is huge performance bottleneck. especially if reliably persisting this

same reason why filesystems are often mounted with noatime attribute !

[ Parent | on HN ]

Re:Safely Dropping MySQL Tables by daenz on Monday July 25, 2022 @04:56PM (#32230810)

Yes, the sensible default for this feature would be opt-out, like noatime, in case you need the performance boost and understand the implications of the choice.

[ Parent | on HN ]

Re:Safely Dropping MySQL Tables by samlambert on Monday July 25, 2022 @09:51PM (#32233347)

This feature has zero performance impact on your database. It is powered by insights which is served from a separate data store.

[ Parent | on HN ]

Re:Safely Dropping MySQL Tables by solardev on Monday July 25, 2022 @10:25PM (#32233541)

I think they meant if you were to add this as a default metadata feature into mainline mysql

[ Parent | on HN ]