PGConf.Russia 2024

There are many open source (and even more proprietary) pg_stat_statements forks that allow you to view query execution plans:

pg_state_plans https://github.com/2ndQuadrant/pg_stat_plans pg_store_planes https://github.com/ossc-db/pg_store_plans pg_stat_monitor https://github.com/percona/pg_stat_monitor

All of them did not suit me in some way and I wrote my own https://github.com/postgredients/pg_stat_query_plans. I'll tell you why and how, and what I would like to add to the original pg_stat_statements so that my extension is not will be needed.

Greenplum use another approach for gather query statistics -command center instead of pg_stat_statements. Command Center is a separate application. So there is no need to store statistics in a shared memory. But you need to send it to a separate process. I'll tell: - implementation details; - why using grpc in PostgreSQL is a bad idea and what other problems are we facing?; - what hooks would be nice to add to PostgreSQL; - how not to slow down on sending data; - what new features could be made using separate application.

Small talk about the experience of interacting with Oracle Forms/Apex on the x86 platform Small talk about the experience of subsequent solutions on Elbrus e2k Small talk about performance/scalability (DB/number of users)

Based on the Funds of Rostec, Rostelecom

A comparative survey of PostgreSQL instruments for spherical geometric data - point, spoint, spoint3, earthdistance, pg_sphere, PostGIS. Search performance questions and kNN search will be covered too.