Bloat in PostgreSQL: A taxonomy Friday 10:50 Casablanca
Twitter: @petervgeoghegan
I’m a PostgreSQL Major Contributor, and committer. I’ve mostly work on performance enhancements. I’m the primary author of parallel CREATE INDEX, which will be in Postgres 11.
I’ve been heavily involved in Postgres since about 2011. It’s a big part of my life. I participate on the -hackers mailing list regularly, and regularly speak at Postgres events.
Yes. This will be my first time going to EU since the Dublin conference in 2013. I’m from Dublin, but I currently live in the United States. I’m looking forward to getting back to the European conference after all these years.
It’s about how VACUUM and other garbage collection mechanisms work, from the ground up. It’s an important topic for DBAs running Postgres at scale, and anybody that’s interested in garbage collection’s theory of operation.
I generally try to give a new take on things. I’m taking a bottom-up approach to talking about VACUUM in my talk, as opposed to the conventional top-down approach. The talk may fill in the gaps for the audience to some degree, because some of the issues are very hard to talk about when you take the conventional approach.
The audience for my talk are users that want to improve their intuitions about how VACUUM works. It’s not a talk that anyone should expect to pick up practical tips from — there have already been plenty of those. I’m trying to do something broader than that, that may or may not be of practical use when dealing with day to day production issues. Under-promising in this way frees me to be a lot more ambitious.
A working knowledge of VACUUM, at a minimum. I don’t want to be too prescriptive, though. If you read the abstract and think that it sounds interesting, go to the talk. If it doesn’t sound interesting, then you should go to some other talk. My talk is not for everyone. Not necessarily because of its considerable technical depth.
Audience members might have to muddle through some parts, but that shouldn’t prevent them from taking something away from it.
I’m a big fan of INCLUDE/covering indexes. They didn’t make the major features list for 11, but perhaps they should have. Using INCLUDE indexes to make queries against larger tables use index-only scans will make all the difference on some installations.
I would say “Cleaning out crocodiles teeth with PostgreSQL indexes”, by Louise Grandjonc, but I already caught that one in San Francisco. I will be attending “Pluggable storage in PostgreSQL”, by Andres Freund, since I haven’t paid enough attention to that work, and need to catch up.