My name is Victor Yegorov. I work as PostgreSQL DBA for the DataEgret company.
I first met PostgreSQL back in 1998, at the time I was developer. Later I focused on administrative tasks, mostly around databases.
Primary database is PostgreSQL (of course), primary OS is Linux.
How do you engage with the PostgreSQL Community?
I follow PostgreSQL mailing lists, answer questions time to time. I’ve sent small patches for the yum repository. My engagement level is quite low, though, as I lost my C skills in recent years.
Have you enjoyed previous pgconf.eu or FOSDEM conferences, either as an
attendee or as speaker?
I’ve visited PGConf.EU conferences in Warsaw and Tallinn previously. Great event to meet people, got to know about new stuff and PostgreSQL internals. For me visiting PGConf.EU is mostly about meeting old and making new friends.
What will your talk be about, exactly? Why this topic?
I will speak about btree indexes, their internals and changes, that will come in this area in the about-to-be-released PostgreSQL 12. In my view, this is one of the most valuable features:
btree indexes are most commonly used ones
currently btree indexes under certain loads tend to accumulate bloat
new changes will help keep indexes smaller (especially multicolumn ones)
no configuration tuning required for this stuff, it just works
What is the audience for your talk?
I will talk about btree index internals, but will not dig into code or low level data structures.
Therefore, everybody is welcome.
What existing knowledge should the attendee have?
Understanding of what btree indexes are and how they work is good, but not necessary.
What is the one feature in PostgreSQL 12 which you like most?
The one I will be speaking: nbtree indexes’ changes.
Which other talk at this year's conference would you like to see?
Which measure, action, feature or activity would—in your
eyes—help to accelerate the adoption of PostgreSQL?
Improved stats system, that provides extra information:
timestamps of system object’s modifications
information about query planning time, sent/received bytes, parallelism level
list of transactions for a session, list of queries for a transaction
locks and waited time for each lock
historical view on the information above
I understand that such complex subsystem requires huge effort. Still, in my opinion, it is required, as currently PostgreSQL stats are updated after transaction completion, which makes it difficult to monitor OLAP systems.