Hi Leonid, I took a look at your second proposal, “Outside of pg_stat_statements: if your query is executed by multiple PostgreSQL instances” — it’s a very practical and interesting topic.
One small suggestion: since Community Over Code is strongly Apache-focused, do you think it might be possible to create some connection to Apache projects (e.g., Cloudberry or the broader Apache ecosystem)? Even a light touch there could help strengthen its fit and improve acceptance chances. Just a thought! Also, in case it’s helpful — the event provides Travel Assistance: https://tac.apache.org/events/current.html. If other community members want to get travel assistance, can apply for it. I'm also preparing a talk and will share it soon. Best, Dianjin Wang On Mon, Mar 30, 2026 at 7:07 PM Leonid Borchuk <[email protected]> wrote: > > Hi! > > Thank you, I opened a proposal for 2 sessions: > > We tried DPDK for network but failed. Why and what we have learned from > this? > Description > > The CPU frequency is practically not growing, but everything else: > network/ssd/ data volumes are growing exponentially. This poses new > challenges for the databases: reduce CPU costs for working with the > infrastructure. The bottleneck of MPP systems is the network. What happens > if the network in Greenplum becomes 10 times faster? We accelerated 5 > times. Then we tried DPDK, but realized that we couldn't move forward > without serious core refinement. I would share what happened to the > database when the network accelerated 5 times. And also why DPDK didn't > start. > What conclusions have we learned and what are we planning to do next > (spoiler: all new changes will be in Apache Cloudberry). > Session format > > Session > Track > > OLAP & Data Analysis > Level > > Intermediate > Language > > English > > Outside of pg_stat_statements: if your query is executed by multiple > PostgreSQL instances > Description > > Let's say you have several PostgreSQL instances, they all execute a single > query, and you want to collect general statistics on how many resources > were spent on executing this query. The built-in pg_stat_statements module > is no longer suitable here, since it works within the same database. I will > present a solution with a similar central idea — collecting data through > query execution hooks, but instead of storing it in PostgreSQL shared > memory, we send raw data to an external agent process. This process is > responsible for aggregating metrics, providing a unified picture across all > instances, as well as additional functions, such as the forced termination > of problematic sessions, while not limited to PostgreSQL: the solution can > collect data from other system components. I will talk about architecture, > product tasks, and share links to the repositories (Apache 2.0 License) > with the code. > Session format > > Session > Track > > Observability > Level > > Advanced > Language > > English > > On Mon, Mar 23, 2026 at 4:02 AM Dianjin Wang <[email protected]> wrote: > > > Hi all, > > > > I’d like to share that the Call for Proposals (CFP) for Community Over > > Code Asia 2026 is now open: > > https://sessionize.com/community-over-code-asia-2026/ > > > > Community Over Code Asia 2026 will be held in Beijing from August 7 to 9, > > 2026. > > > > I’d like to encourage everyone in the Apache Cloudberry community to > > consider submitting talk proposals. There are multiple tracks that > > could be a good fit for Cloudberry-related topics, including for > > example: > > > > - Data + AI > > - Data Lake & Data Warehouse > > - Incubator > > - OLAP & Data Analysis > > > > You can also find the full list of tracks here: > > https://asia.communityovercode.org/tracks.html > > > > This is a great opportunity to share our technical progress, community > > journey, user stories, ecosystem work, and ideas around Apache > > Cloudberry with the broader open source community. > > > > The CFP deadline is 21 April 2026, so now is a good time to start > > preparing proposals. > > > > If you already have a topic in mind but would like help refining the > > title, abstract, or track selection, feel free to start a discussion > > on the mailing list. > > > > Best, > > Dianjin Wang > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
