Firefly2026-05-192026-05-224https://www.pgevents.ca/events/pgconfdev2026/schedule/07:3001:00Xerox (1500)A breakfast for new members new members of the community. Is this your first in-person PostgreSQL event? Are you a new member of the community? Then this breakfast is for you. Meet other newcomers along with experienced members of the community who will be welcoming you at this breakfast.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/712/Other IdeasFloor DreesPeter V Geoghegan07:3001:00Concoursehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/742/Other Ideas08:3000:20Fletcher (1900)Logistics for Tuesday sessions only.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/710/PanelClaire GiordanoRobert Haas09:0000:50Fletcher (1900)While code contributions often take center stage, a project’s continued success depends on much more than just great technology. This roundtable brings together a diverse group of PostgreSQL community members to share their personal journeys and highlight critical areas where participation is still lacking. We will explore the hurdles facing new contributors and discuss practical strategies to prevent volunteer burnout. Following a moderated discussion, we invite the audience to join the conversation with their own questions and insights.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/558/PanelFloor DreesHari KiranJimmy AngelakosMiaolai ZhouValeria Kaplan09:0000:50Canfor (1600)Postgres on Kubernetes, and the immutable container images which these deployments are based on, are becoming a more common model for deploying Postgres. Immutable images are also a key part of easy deployment options for local Postgres like postgres.app. A number of recent developments, such as the extension_control_path GUC and Kubernetes’ ImageVolume feature have made it easier for Postgres on Kubernetes to use extensions, but there is still more to be done. Join us for an open discussion exploring the challenges for extensions with Postgres deployments based on immutable images and possible solutions.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/618/Community Discussion - OpenAlastair TurnerDavid E. WheelerFloor DreesYurii Rashkovskii09:0000:50Cominco (1415)PostgreSQL packagers don't just package PostgreSQL itself -- they also package a whole ecosystem around it However many of those packages are not visible to everyone. What can be done to improve things? How can we improve cross-distro packaging? Let's discuss together!https://www.pgevents.ca/events/pgconfdev2026/schedule/session/722/Community Discussion - OpenChristoph BergDevrim Gündüz09:0000:50Scotiabank (1315)This is a review of the current efforts for exhibiting PostgreSQL at non-PostgreSQL conferences and what's coming up for future events. Learn what we currently do for exhibitions, such as planning, budgeting, and recruiting. Then help us improve what we do, and help us plan to cover existing or additional conferences. This is not possible without volunteers so please come to see where help is needed and how you might get involved to help PostgreSQL network around the world!https://www.pgevents.ca/events/pgconfdev2026/schedule/session/457/Community Discussion - OpenMark WongRobert Treat09:0000:50Xerox (1500)Want to hack on Postgres but don't know where to start? This workshop is your onboarding to the Postgres hacking world. We'll start from scratch: clone the repo, set up your development environment, compile, and write your first patch. Then we'll learn the hacker's toolkit -- debugging , writing regression tests, profiling query execution, and navigating 2 million lines and 30+ years of battle-tested C code. We'll intentionally break things to understand how they work, and maybe experiment with AI pair programming on database internals (results vary). Bring a Linux, Mac, or WSL-capable laptop and your curiosity. Even if your setup is different, we'll try to make it work. By the end, I hope, you'll have the confidence to dive into Postgres source and start contributing.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/489/WorkshopAndrey Borodin09:0000:50RBC Executive (2200)This is a meeting for all PostgreSQL committers to discuss current issues related to PostgreSQL development and the technical side of the PostgreSQL project.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/519/Community Discussion - ClosedPeter Eisentraut10:0000:30Concoursehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/743/Other Ideas10:3000:50Fletcher (1900)Postgres adds about 180 features and changes every year, yet it is missing some major ones. This talk explains what those features are, and why they have not been implemented. The features include sharding, TDE, global indexes, and multi-master replication.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/471/50-Minute TalkBruce Momjian10:3000:50Labatt (1700)Getting involved in the PostgreSQL community can be difficult; how can we make it easier? New community members often ask the same questions: Where do I start? How do I connect? How can I contribute? In this session, we'd like to discuss: 1. How do most people first interact with the PostgreSQL community (e.g. in person, mailing list, Slack, Discord, etc.)? What factors affect whether they have a good experience or a poor one, and what should be trying to do improve the experience that newcomers have on average? 2. What resources already exist to help onboard new community members, and what needs to be created or updated? Importantly, we need resources for people who wish to be involved in different ways: attending user groups or conferences, organizing them, reporting bugs, as a developer, etc. 3. How do we promote the resources that already exist, or new ones that get created, so that as many people as possible discover them? 4. What can we do to make sure that our resources as broadly accessible as possible, so that our community can welcome people of diverse backgrounds? The goal of the session is to identify opportunities for improvement and people who would be interested in helping to close those gaps.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/476/Community Discussion - Working GroupCornelia BiacsicsHari KiranRobert Haas10:3000:50Canfor (1600)The SQL standards are famous for being more honoured in the breach than the observance, but they’re far from alone. Authentication and authorisation protocols like OAuth and OIDC have so many options, and so many parts of the standard are regarded as optional even if they are not, that implementations from large providers may be outright incompatible with each other. Extensions could fit well here, tracking the particular implementation of an enterprise vendor or cloud provider. Our working group session will allow you to hear from people who have built the extension points, and the extensions. You will also have the opportunity to cross through the wall of the fishbowl and join the panel for a round of discussion.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/655/Community Discussion - Working GroupAlastair TurnerDavid E. WheelerFloor DreesYurii Rashkovskii10:3000:50Cominco (1415)As PostgreSQL’s native logical replication matures, it is increasingly being adopted for more workloads. However, as adoption increases, so do the challenges. This session is designed as an open forum to gather field feedback, prioritize the community’s development efforts, and brainstorm architectural approaches for the next generation of logical replication features. We will focus the discussion on following areas with an open mind to discuss others: 1. Closing the Observability and Usability Gaps Conflict Management: Discussing the progress and design of the Conflict Log Table (CLT) and the path toward standardized conflict resolution strategies. DDL Replication: Assessing the current state of proposals and identifying the "must-have" syntax and safety guards for native DDL support. Failover Slots: Strengthening the reliability of slots during physical-to-logical transitions and ensuring high availability for replication consumers. 2. Field Feedback and Critical Bug Triage We invite users and developers to share overlooked edge cases or critical bottlenecks encountered in large-scale deployments. Identifying minor missing features or cryptic error messages—that hinder developer productivity. Session Goal The objective of this session is to move beyond "feature wishlists" and toward actionable consensus. We aim to identify which features are blockers for wider adoption and establish a priority for the upcoming development cycle(s).https://www.pgevents.ca/events/pgconfdev2026/schedule/session/718/Community Discussion - Working GroupAmit Kapila10:3000:50Scotiabank (1315)Slonik Events Canada is the NPO that runs PGConf.dev. This meeting is open to everyone but you must be a member of Slonik Events Canada as of 2026-04-28 to be eligible to vote. You can join Slonik Events Canada by visiting https://www.pgevents.ca/membership/ We will present the 2025 financial statements, provide an update on operations and have elections for the board of directors. There will also be Q&A session.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/529/Community Discussion - OpenDaniel GustafssonJonathan KatzMagnus HaganderSteve Singer10:3000:50Xerox (1500)A session for people interested in translation (national language support, NLS) and translation tooling (gettext etc.). We can discuss various things about how to improve the translations tooling, recruit translators, make the processes efficient and sustainable, and so on.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/543/Community Discussion - Working GroupPeter Eisentraut11:3000:50Fletcher (1900)In this panel discussion, we'll be asking three PostgreSQL committers -- Andres Freund, Heikki Linnakangas, and Tom Lane -- to react in real time to PostgreSQL patch ideas that haven't been disclosed to them in advance. For each idea, we'll ask them whether it's a good idea that would be worth including in PostgreSQL. Even if they think it's a terrible idea, we'll also want to hear how they would go about trying to implement it if for some crazy reason they decided to do so. What would be the main technical challenges? What would be the important design considerations? How would they decompose it into smaller projects for ease of review? How would they test it, validate performance, and assess any backward-compatibility considerations? The moderator will prepare a list of ideas to be proposed to the panel during the session, and will accept suggestions for additional ideas in advance of and during the session via Discord chat. This panel discussion will be moderated by Robert Haas.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/512/PanelAndres FreundHeikki LinnakangasRobert HaasTom Lane11:3000:50Labatt (1700)An open discussion on how the PostgreSQL community recognizes contributions and contributors. Starts with a short presentation on how the Contributors Committee currently operates, and plans for changes. Then we move to open discussion for improvements and missed opportunities. This session will utilize the Chatham House Rule[1] in order to foster an open and inclusive discussion. [1]https://www.chathamhouse.org/about-us/chatham-house-rulehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/467/Community Discussion - OpenJoe Conway11:3000:50Canfor (1600)Postgres major version upgrades are a topic of frequent complaints. Adding extensions into the mix just makes things more complicated. Some extensions can just be uninstalled and reinstalled after the upgrade. Those that affect the data stored, including those providing data types and access methods need to ensure compatibility across Postgres major versions to allow the extensions to be upgraded before the database. Join us for an open discussion about the complications of upgrading Postgres with extensions installed and what changes could be proposed to ease the pain in this area.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/619/Community Discussion - OpenAlastair TurnerDavid E. WheelerFloor DreesYurii Rashkovskii11:3000:50Cominco (1415)In this session we will discuss new and proven ideas on how to organize Meetups as a way to bring the community together on a smaller scale. Everyone can start a Meetup, but it takes an effort to keep the events going and thriving. We will look at what works well, what are other Meetup groups doing in order to improve their attendance and make the Meetup a good place for everyone. The ideas, notes and results will be documented in the PostgreSQL Wiki.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/644/Community Discussion - OpenAndreas ScherbaumCornelia Biacsics11:3000:50Scotiabank (1315)Transparent Data Encryption (TDE) is a critical requirement for enterprise compliance, yet its implementation in PostgreSQL remains a complex and historically controversial challenge. This session brings together contributors who have implemented TDE in PostgreSQL variants alongside other experts to synchronize efforts. Rather than debating the merits of TDE, we will focus on resolving active technical blockers in the storage manager, WAL handling, and Key Management integration to ensure a stable, extensible framework for the ecosystem. The goal of this session is to end with a clear consensus on the technical path forward of TDE for PostgreSQL.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/559/Community Discussion - Working GroupKai Wagner11:3000:50Xerox (1500)A conversation on the state of OAuth client authentication in Postgres, and possible future directions. Potential areas of discussion include - The current state of integration with clients and proxies - Desirable client flows, in addition to the Device Flow implementation - Token caching and refresh - Sender constraints on tokens - Other features, as desired by attendeeshttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/524/Community Discussion - Working GroupJacob Champion12:3001:00Concoursehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/744/Other Ideas13:3000:50Fletcher (1900)PostgreSQL isn't actually terrible, of course. But it's not perfect, either, and it's important to be honest about what is wrong with it so we can improve it. After 25 years of working with PostgreSQL, and consulting with literally hundreds of clients doing real-world work on very large systems, this is a discussion about what pain points they run into, how we mitigate them, and how PostgreSQL could remove them.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/658/50-Minute TalkChristophe Pettus13:3000:50Labatt (1700)The [PostgreSQL Security Team](https://www.postgresql.org/support/security/) receives vulnerability reports, looks for similar defects, completes the fixes, and publishes CVE details. We're calling this session to hear your feedback on how we can do better. Questions to think about: - When you compare the PostgreSQL vulnerability lifecycle to organizations that handle vulnerabilities better, what is different? - When has a PostgreSQL vulnerability or vulnerability fix created unusual problems for you? What made it bad? - Fixes appear in git on the Monday before the [minor release](https://www.postgresql.org/developer/roadmap/). For coordinated vulnerability disclosure (CVD), we've discussed removing public access until the Thursday release. There would be a process to qualify for early access. What should we know about your use of git during release weeks? - If making a new RDBMS, what would you avoid copying from the PostgreSQL security model?https://www.pgevents.ca/events/pgconfdev2026/schedule/session/506/Community Discussion - OpenJoe ConwayNoah Misch13:3000:50Canfor (1600)Postgres publishes numerous APIs in its header files and hooks to inject into its execution. By what process are new hooks and APIs introduced? How is the decision made to add a new API or make an existing API public? And what’s the process to introduce new hooks? In this Open Community Discussion, we’ll examine the history, explore the intentions, and attempt to arrive at a description of the policy and process involved in providing and supporting hooks and APIs for extension developers.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/621/Community Discussion - OpenAlastair TurnerDavid E. WheelerFloor DreesYurii Rashkovskii13:3000:50Scotiabank (1315)The PostgreSQL Community Association (PGCA) is a Canadian Not For Profit organization chartered by the PostgreSQL core team to hold and protect the Postgres brand assets globally, including domain names and trademarks for the PostgreSQL Project. This session will contain the Annual General Meeting (AGM), followed by a board meeting, followed by informal Q&A for the public. The whole session is open to the public, but only members may participate actively in the formal meeting portions.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/478/Community Discussion - Working GroupClaire GiordanoDave PageJaime CasanovaJonathan KatzPeter EisentrautSteve Singer13:3000:50Xerox (1500)Open discussion with optional short presentations on the topic threads in the PostgreSQL backend. The intention is to give brief updates on scope, subprojects, progress, research topics and problem statements to set the scene for later discussions during the conference. (Actual "speakers" with presentations vs open discussion time to be decided, names listed are just for schedule planning purposes.)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/727/Community Discussion - Working GroupGreg BurdHeikki LinnakangasMatthias van de MeentPeter EisentrautThomas Munro14:3000:50Fletcher (1900)The PostgreSQL event landscape has never been richer — ranging from small local meetups with just a handful of participants to large international conferences with hundreds of attendees from across the globe. While human connection can form in different settings, Postgres events serve as a pressure cooker for PostgreSQL’s technical evolution, community growth, and individual development. Large PostgreSQL conferences, in particular, are complex systems with multiple stakeholders: individual attendees, companies, organisers and volunteers, sponsors, and speakers — each with their own interests and goals. In this talk, marking 30 years of the project, I’ll zoom in on PostgreSQL events — why people attend, why companies sponsor, and why being a speaker matters. I’ll explore what makes community conference organising teams work, what motivates organisers to keep “getting together for a gig,” and where they struggle. I’ll highlight how connections that emerge around events contribute to personal and business growth and overall ecosystem resilience, before taking you on a visual journey through key PostgreSQL milestones. Here’s to 30 more years of changing the course of open source — and to Postgres events that are fun, welcoming, and full of connections that last a lifetime!https://www.pgevents.ca/events/pgconfdev2026/schedule/session/665/50-Minute TalkValeria Kaplan14:3000:50Labatt (1700)The role of the Community Code of Conduct Committee has been reactive. Reports come in, there's an investigation, a (hopefully timely) decision is made, actions taken, reports closed. The Committee has been asked to serve as the point of contact for concerns and reports for events and while the option is there, we would like to discourage it, and instead propose more local response system. There’s a couple of challenges with the current model. The PostgreSQL Community Code of Conduct Committee is globally distributed, but typically has no more than two members per ~ time zone—and in most regions, only one. Without someone physically present at an event, it becomes difficult to respond quickly to reports or address incidents as they occur. This has, at times, led to drawn-out resolution processes, increased frustration, and situations where unsafe conditions persisted longer than they should have. Unfortunately, we suspect it has eroded trust in the committee. Code of Conduct work is demanding and requires constant attentiveness. To make it more sustainable, there’s an opportunity to standardize how incidents are reported and addressed, and to do so locally. A proposal is being drafted to require having a CoC response team on-site at community-recognized events. Let's discuss what that would need to look like, and the support required for local organizing teams that would need to come from PostgreSQL Europe, PostgreSQL United States, or other organizations.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/606/Community Discussion - OpenFloor DreesStacey Haysler14:3000:50Canfor (1600)If there is a piece of functionality you’d like to see in Postgres, but isn’t there, how do you best scratch that itch? Do you create a new extension? Do you join an existing extension effort? Do you propose changes to core Postgres? Join us for an open discussion on when to choose which of these options, why the second option is so seldom exercised and what we may be able to do to remedy that.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/620/Community Discussion - OpenAlastair TurnerDavid E. WheelerFloor DreesYurii Rashkovskii14:3000:50Cominco (1415)We kick off with a short DEV/DBA/DBRE panel discussion to surface the most common “Postgres at scale” failures. Then the mic is open and attendees can step up for a round of 5-minute lightning confessions : A real production “obvious fix” that backfired, the metric that proved it, and what they’d do differently. Panel can chime in at the end with a best practice or an alternate solution.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/703/Community Discussion - OpenAnts AasmaHenrietta DombrovskayaPavlo Golub14:3000:50Xerox (1500)Myself and Peter Eisentraut are working on implementing SQL/PGQ (SQL:2023) standard into PostgreSQL [1]. With this feature, PostgreSQL users will be able to query their relational data as graph data in PostgreSQL itself. Today, users can use PostgreSQL as a graph database using extensions like Apache AGE, specialized forks like AgensGraph, or algorithmic libraries like pgRouting. This developer meeting aims to bring graph database experts in the PostgreSQL ecosystem together. The communities around the products which are already used in the field have an understanding of the customer needs which can be used to prioritize the next set of features in SQL/PGQ core implementation. These products in turn can benefit from adopting SQL/PGQ as their underlying implementation. Through this symbiosis the wider ecosystem can thrive. Specifically the relationship between Apache/AGE and SQL/PGQ implementation in core is expected to evolve similar to the relationship between pg_partman and in-core partitioning. We will discuss various collaboration options and come up with a mutually beneficial roadmap. We expect the following developers and field experts to participate in the meeting. o. Peter Eisentraut and Ashutosh Bapat, authors of SQL/PGQ implementation o. Junwang Zhao (Apache/AGE), Henson Choi (AgensGraph), and reviewers of SQL/PGQ implementation o. John Gemignani, committer Apache/AGE o. Representatives from EdgeDB and pgRouting. Specific names need to be finalized. We expect the feature to be available in PG 19 or merged upstream earlier in PG 20. The agenda of the meeting doesn’t change much irrespective of the outcome. It will influence the development of the feature after the first version is committed. [1] https://www.postgresql.org/message-id/a855795d-e697-4fa5-8698-d20122126567%40eisentraut.orghttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/605/Community Discussion - OpenAshutosh Bapat14:3000:50RBC Executive (2200)The specific team using the space will receive details elsewhere.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/505/Community Discussion - ClosedNoah Misch15:3000:30Concoursehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/745/Other Ideas16:0000:50Fletcher (1900)“Those that fail to learn from history are doomed to repeat it!” The PostgreSQL community has a well-documented history in the form of mailing lists, commit logs, and conference talks. We are building this Postgres history together: “The good, the bad, and the ugly” all inform where we go next. As a community we can learn from both our failures and our successes. In this roundtable-style panel, Postgres committers Àlvaro Herrera, Daniel Gustafsson, Peter Eisentraut, and Thomas Munro will share epic failures and unexpected successes from their work on Postgres: what they were trying to do, what actually happened, and what they’d do differently next time. Think of this roundtable as group therapy for PostgreSQL hackers. You’ll leave knowing that you’re not alone. Because one of the best parts about group therapy is realizing that others have had similar (or worse) experiences, too. The Postgres committers on this panel are heroes—and will talk openly about times they fell flat on their face, or were surprised by the uptake on something they didn’t think was important. Moderated by Claire Giordano and Greg Burd, with time for Q&A.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/637/PanelÁlvaro HerreraClaire GiordanoDaniel GustafssonGreg BurdPeter EisentrautThomas Munro16:0000:50Labatt (1700)What does it mean to be "**PostgreSQL compatible**"? As PostgreSQL becomes "the new Linux" for the enterprise, this question becomes increasingly important. This session invites Postgres developers, contributors, and community members to continue the work of defining a practical framework of criteria and tests for PostgreSQL compatibility. **Building upon the foundations set in our [session at PGConf.EU 2025 in Riga](https://2025.pgconf.eu/community-events/establishing-the-postgresql-standard-whats-postgres-compatible/),** this session will pivot from the idea of a strict binary "pass/fail" certification to designing a **granular compatibility matrix** — a weighted checklist distinguishing critical (Core) features from peripheral ones, with room for specific exceptions (e.g., "Managed" Postgres restrictions on superusers) **Agenda** * **Introduction & Recap:** A brief overview of the landscape, the consensus from Riga, and the goals of this session. * **Facilitated Discussion:** Structured conversation across key compatibility dimensions. * **Synthesis & Next Steps:** Capture consensus and outline the path forward. **Discussion Topics** * **SQL & Core Behavior:** What's required from "Part II. The SQL Language"? How do we handle implied behaviors (like `plpgsql` is required for ``TRIGGER``s), undocumented-but-relied-upon features (e.g., `INSERT...ORDER BY`), and transaction isolation semantics? * **Test Harness Design:** An **independent** suite tracking Postgres versions—testing compliance, not bug-for-bug compatibility * **Ecosystem & Connectivity:** Version reporting, driver compatibility, `pg_dump` portability, and `pg_catalog` availability * **Backup & Replication:** WAL, streaming, hybrid clusters (mixing Vanilla and Vendor nodes), and proprietary extensions in the WAL stream * **Compliance Matrix:** Required vs. Optional tests, accommodating managed environments, and catching "silent failures" We aim to leave with refined compatibility criteria and a concrete roadmap for continued collaboration.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/450/Community Discussion - OpenHenrietta DombrovskayaJimmy Angelakos16:0000:50Canfor (1600)Interested in all things Extensions, but just had too many interesting options this morning, all is not lost. We will be reading out summaries of the extension open discussion sessions - How immutability challenges extension packaging and distribution - Extensions and upgrades - To extend, to contribute, or to petition to core? - Hooks and APIs: What to expose in the core with some time left over for Q&A from those who were not able to make the full sessions.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/622/Community Discussion - OpenAlastair TurnerDavid E. WheelerFloor DreesYurii Rashkovskii16:0000:50Xerox (1500)This session is aimed at hackers who have either built batched or vectorized executors elsewhere, or have tried to graft OLAP storage and execution onto Postgres and run into the executor boundary. The goal is a concrete working conversation about the primitives themselves: where batches enter and exit the plan tree, how a batched interface coexists with the existing tuple path, what the TAM and expression-evaluation APIs need to expose, and which incremental steps are tractable in the next cycle or two. Recent work on the pgsql-hackers 'Batching in executor' thread has started in this direction, pulling page-sized batches of HeapTuples into Scan nodes using some new TAM APIs as a first step.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/721/Community Discussion - Working GroupAmit Langote17:0004:00ConcourseJoin a group of Postgres community folks for dinner and casual chatting on technical or personal topics. Meet new people or reconnect with people you've known for years but haven't had dinner with before. How it works: sign up at the linked Google form; on the day you will receive an email with your group number and leader; meet your leader and group at reception at 17:00; walk together to the restaurant; eat talk and learn; finally pay for your meal and walk home. Note that this dinner is a **self-pay**. More information and [sign-up form here](https://2026.pgconf.dev/attend/social#meet).https://www.pgevents.ca/events/pgconfdev2026/schedule/session/707/Other IdeasPaul Ramsey17:3001:00ConcourseEveryone is welcome to a social run after one of the conference days where you can see some of the city and chat with fellow PostgreSQL people. Pace will be selected based on who shows up so it is comfortable for everyone, we aim for a social pace where people can chat. If there are a lot of people there will be multiple pace groups. Distance will be somewhere between 5 and 10 km.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/623/Other IdeasYurii Rashkovskii07:3001:00Canfor (1600)Come and have breakfast with Postgres Women! This breakfast is a wonderful opportunity to connect with other women in the PostgreSQL community, share experiences, and build meaningful relationships in a welcoming environment. Whether you're a long-time contributor or new to the community, we'd love to have you join us! The event is open to everyone who identifies as a woman or non-binary, and to allies of every gender who want to actively support diversity, inclusion, and equal opportunity in tech.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/530/Other IdeasStacey Haysler07:3001:00Concoursehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/746/Other Ideas08:3000:25Fletcher (1900)We will share logistical information specific to Wednesday and Thursday and give away posters celebrating PostgreSQL's 30th anniversary.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/706/PanelJonathan KatzMelanie Plageman09:0000:50Fletcher (1900)How do we find and nurture the next generation of open source contributors? Unlike commercial companies, open source projects don’t have legions of recruiters to bring people into the fold—and yet our projects need a steady stream of new contributors. Or should open source projects assume that new contributors (and future committers) will continue to “self-select” onto the project? The PostgreSQL open source project turns 30 in 2026: Happy Birthday! It has evolved from a small project that some referred to as “just a toy”—to today, where Postgres is thriving with an active community and a vast ecosystem of extensions and tooling. The project is clearly doing some things right. Postgres is hugely popular, with a healthy upstream open source community plus a host of companies and products built around Postgres itself. But what happens when the current generation of Postgres committers step back or retire—where will the next generation of Postgres contributors come from? This talk is a reprise of a talk given earlier this year on the Main Track at FOSDEM—with more time for audience Q&A, so we can discuss together how contributors find their way into Postgres: what is working, what did not, and where we’re still struggling.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/651/50-Minute TalkClaire Giordano09:0000:50Labatt (1700)Postgres supports AIO since version 18, and a most of the basic executor nodes were already modified to leverage this capability. In many cases this results in significant performance improvements, particularly on storage that requires prefetching. Index scans are one of the remaining pieces that still don't leverage AIO, despite the obvious benefits of prefetching with random I/O. In this talk we will discuss the work we've done on using AIO for index scans - the current state of the work, what were (are) the main challenges and difficulties of this multi-year project. We'll explain the basic concepts introduced by the patches (batching, additions to index AM interface, ...) and how it all works together. We'll also share some numbers on performance.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/659/50-Minute TalkPeter V GeogheganTomas Vondra09:0000:50Canfor (1600)Connection pooling is critical infrastructure for PostgreSQL at scale, but existing poolers like PgBouncer operate at the protocol level without deep integration into distributed database architectures. This talk presents our experience building a custom connection pooler for multigres, a distributed PostgreSQL system, that natively supports the extended query protocol (Parse/Bind/Execute), per-user connection pools for Row-Level Security compatibility, and prepared statement consolidation across clients. We'll dive into the technical challenges we encountered: implementing settings-based connection routing with an LRU cache for fast pointer-equality comparisons, managing connection affinity for transactions while maximizing pool utilization, and handling the complexities of PostgreSQL's extended query protocol across a distributed query path. Attendees will learn about our three-tier pool architecture (admin, regular, and reserved pools), how we route connections through hash buckets based on session settings, and the tradeoffs we made between connection reuse and protocol correctness. Whether you're building database infrastructure, evaluating connection pooling strategies, or curious about PostgreSQL protocol internals, this talk offers practical insights from implementing a production-grade pooler from scratch.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/692/50-Minute TalkManan Gupta10:0000:30Concoursehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/747/Other Ideas10:3000:50Fletcher (1900)Psycopg is the de facto standard PostgreSQL adapter for Python (or, depending on whom you ask, the Python adapter for PostgreSQL). From its inception, Psycopg has been built on top of libpq, PostgreSQL's official C client library. This design choice has brought clear benefits: libpq handles the complexity of the wire protocol, query state management, and many low-level details, sparing users an entire class of bugs while delivering solid performance in a language not historically known for its raw speed. At the same time, relying on an external C library comes with trade-offs. Build and deployment become more complex; choices must be made between tight isolation and system integration; and subtle dependency issues can arise. For these reasons, many alternative PostgreSQL drivers in the Python ecosystem have opted to bypass libpq entirely and work directly at the protocol level. Even when libpq is used, its abstractions do not always align perfectly with the needs of higher-level clients. Psycopg 3 is likely among the most demanding libpq consumers, and over the years it has occasionally had to reimplement substantial pieces of functionality that one might reasonably expect libpq itself to provide. We will discuss a few concrete examples: - A success story: pipeline mode, thanks to Simon's work—one of his many enduring gifts to the PostgreSQL ecosystem. - A less happy experience: asynchronous connections, and the surprising amount of functionality that must be rewritten once timeouts enter the picture. - A future challenge: logical replication support, which may require “drilling a hole” through libpq to access the underlying socket. This talk reflects on two decades of largely successful collaboration between Psycopg and libpq. By highlighting the pain points we have encountered, we hope to inform future libpq evolution, set realistic expectations for client authors, and clarify when reimplementing functionality is not a failure—but simply an acknowledgment that libpq, powerful as it is, cannot solve every problem.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/520/50-Minute TalkDaniele Varrazzo10:3000:50Labatt (1700)The main limitation is that unique keys must include the partition key, which can be restrictive for many use cases. A global index addresses this issue by enabling unique indexes that span the entire partitioned hierarchy, removing the need for partition key inclusion in primary keys. In this talk, we share our experience experimenting with the implementation of global indexes in PostgreSQL. We present the overall design, including necessary changes to storage structures, handling of partition attachment and detachment, and strategies to improve vacuum operations for global indexes. Additionally, we discuss the technical challenges encountered during this experiment, such as identifying the optimal vacuum strategy, ensuring efficient locking across the partition hierarchy. Our findings aim to provide insights into the feasibility and potential benefits of global indexes in PostgreSQL, as well as offer recommendations for future improvements.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/449/50-Minute TalkDilip Kumar10:3000:50Canfor (1600)PostgreSQL was originally architected for an era of Uniform Memory Access (UMA) and modest CPU core counts. As the industry shifts toward high-density, multi-socket servers featuring 128+ cores, non-linear NUMA topologies, and emerging CXL memory tiers, the traditional "flat" shared memory model faces structural limitations. While continuous community optimizations have been highly effective, the overhead of maintaining global state is approaching a point of diminishing returns on modern hardware. This session analyzes the systemic bottlenecks that emerge at extreme scale—such as cacheline contention on global locks and the interconnect fabric strain during massive parallel scans—and argues that data locality must evolve from an optimization hint into a core architectural concern. This community proposal explores optimizing PostgreSQL for modern hardware by partitioning global state structures to minimize synchronization overhead, investigating tiered buffer management for CXL-enabled memory hierarchies, and leveraging adaptive scheduling to better utilize heterogeneous CPU resources. By decoupling synchronization from global memory, the talk explores how the kernel can maintain its core identity while scaling to next-generation hardware. Finally, we’ll look at a phased approach—starting with extension hooks and moving toward core locking refactors. The idea isn't to rewrite Postgres, but to find a practical way for the existing engine to handle the hardware we’re actually seeing in the data center today.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/535/50-Minute TalkHaibo Yan11:3000:25Fletcher (1900)There's always been a need for a mechanism to get rid of table bloat. VACUUM FULL does that already, but it comes with a potentially long period during which the table cannot be accessed or modified. Users discover to much frustration that Postgres does not offer any solutions to this problem, and they eventually turn to external tools. Enter REPACK CONCURRENTLY. Intended to be integrated in Postgres 19, we hope it will offer peace of mind to thousands of DBAs around the world. But what is it? How does it work? We intend to explain all that every user will need to know about it, and then some.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/653/25-Minute TalkÁlvaro Herrera11:3000:25Labatt (1700)Even extremely rare data races and edge cases can compromise durability or consistency. At Postgres scale, what's “almost impossible” quickly becomes inevitable—it will happen many times today, and often in surprising ways. TAP tests with injection points are primarily about "wait and wake" synchronization. In this talk, I’ll share a case study of concurrency bugs I discovered using this approach. Beginners will learn the basics of testing for race conditions and may discover new, unexplored test areas. For experienced hackers, I’ll discuss how injection point facilities could be extended and generalized to achieve broader coverage.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/455/25-Minute TalkAndrey Borodin11:3000:25Canfor (1600)This talk will primarily explore how PostgreSQL internally represents and processes data values, then briefly discuss the performance implications of these design choices. We'll cover storage formats, memory alignment, and indexing. Through visual diagrams, you'll see how seemingly small decisions -- like using variable-length versus fixed-length data types -- can significantly affect query speed, disk usage, and memory efficiency. The goal is to provide practical insights for developing high-performance PostgreSQL applications by offering a deeper understanding of its internal value handling. We'll also touch upon future PostgreSQL developments, including automatic reordering of column values.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/474/25-Minute TalkAmul Sul12:0001:00Concoursehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/748/Other Ideas13:0000:50Fletcher (1900)Compilers and modern CPUs go to immense efforts make code run fast. For programmers, even code that at first glance may appear quite optimal can often contain many sub-optimal aspects that could be changed to help give the compiler and CPU the things they need to make the code run faster. In this talk, we'll go through some examples of what I discovered on a recent journey to make tuple deformation faster in PostgreSQL. There were many independent improvements made, and I'd like to talk about these, as there might be other places where similar changes could be made. For each change, we'll go into detail about why that change was made and talk about why this helped performance. When relevant, we'll go through a CPU profiling demonstration to show how the given change helps. In other cases, benchmark results will be shown to demonstrate that the change had an impact on performance and by how much. Finally, I will talk about what could be done in the future to further speed up tuple deformation, and I'll also leave some tips for people who would like to go on a similar journey.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/624/50-Minute TalkDavid Rowley13:0000:50Labatt (1700)pg_lake is a set of extensions that adds comprehensive support for creating and querying Iceberg tables in Postgres, and extends existing commands to query/import/export files in data lakes. Underneath, it accelerates analytics queries using DuckDB, which runs in a separate Postgres-protocol speaking process and can give enormous performance boosts for analytical queries. The Iceberg specification defines a way to store analytics-optimized tables in object stores like Amazon S3. Pg_lake implements Iceberg in a way that's deeply integrated into Postgres, such that you create Iceberg tables as easily as Postgres tables, perform transactions across Postgres and Iceberg tables, and use almost all Postgres features as usual. This talk will go through the architectural decisions we made in developing the pg_lake extension, and how we navigated our way around the various extension APIs.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/633/50-Minute TalkMarco Slot13:0000:50Canfor (1600)Optimizer statistics currently consist of two types: regular statistics concerning a given column in a table, and extended statistics which cover relationships between combinations of a defined set of columns in a given table. Currently there is no way to cover relationships between columns in two different tables, and no way to filter and weigh statistics in one table based upon how frequently the rows are joined to another table. This talk will cover the potential value of such statistics for query planning, a proposed data model for storing such statistics, and how those statistics would actually be collected and maintained.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/570/50-Minute TalkCorey Huinker14:0000:50Fletcher (1900)PostgreSQL’s query planner attempts to estimate the runtime cost of various plans, but those estimates can be based on statistics which are sometimes misleading and can change over time. This means that the planner will sometimes switch from a good plan that runs quickly to a poor one that runs extremely slowly, sometimes without warning. At other times, even the initial choice of plan will be suboptimal. Historically, PostgreSQL has provided few ways for users to control planner behavior, making such problems difficult to prevent or resolve. In this talk, I’ll discuss my ongoing work on pg_plan_advice, a proposed addition to PostgreSQL which aims to address this issue. pg_plan_advice is intended to serve a variety of use cases, including (1) regenerating in whole or in part a plan previously discovered to work well, (2) enforcing choice of an alternate plan that the user prefers over the one that the planner would normally select, or (3) debugging the failure of the planner to produce what the user believes to be the correct plan. In this talk, I’ll give an overview of what this module does and how it does that, what problems had to be solved in order to enable it to do those things, the current status of the patch, and the problems that remain to be solved. In addition, I’ll briefly discuss potential future features that could use this feature as scaffolding.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/503/50-Minute TalkRobert Haas14:0000:50Labatt (1700)Logical replication is an essential tool for modern PostgreSQL environments, yet it often struggles to match the throughput of physical streaming replication. As write-heavy workloads scale, the current architecture faces two primary bottlenecks: the serialized nature of the apply process and the redundant CPU/IO cost of decoding the same WAL multiple times for different consumers. In this session, we examine the internal mechanics of these bottlenecks and the ongoing efforts to overcome them. We will focus on two major architectural shifts: Parallel Apply: We will discuss the implementation of concurrent transaction execution on the subscriber. This includes the logic required to maintain transactional atomicity and the complex challenge of managing commit ordering and dependencies across parallel workers. Centralized Decoding: An exploration of a "decode once, serve many" model. By sharing Logical Change Records (LCRs) across multiple wal_sender processes, we can significantly reduce the resource footprint on the primary node and eliminate the inefficiency of re-reading and re-decoding the same WAL segments for different downstream consumers. This section will cover the high-level ideas and key challenges in moving to this architecture. Attendees will walk away with a technical understanding of these emerging features, their impact on PostgreSQL internals, and performance benchmarks with a work-in-progress patch for parallel apply.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/526/50-Minute TalkAmit KapilaHayato Kuroda14:0000:50Canfor (1600)Moving PostgreSQL to distributed, cloud-native architectures exposes assumptions that work well on single nodes but break across multiple nodes. This session examines the technical details through concrete examples — explain plan differences, cardinality estimation across nodes, transaction coordination approaches, and consistency model trade-offs — drawing on experience from Aurora DSQL and patterns emerging in other distributed PostgreSQL implementations. We'll look at what changes in distributed deployments: data dictionary implementations, ACID guarantee approaches, and where performance implications appear. This is a technical examination of open problems and opportunities for community collaboration, focusing on what worked, what didn't, and what remains unsolved as PostgreSQL is adapted to (and adopted in) cloud-native environments.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/656/50-Minute TalkRaluca Constantin15:0000:30Concoursehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/749/Other Ideas15:3000:25Fletcher (1900)Preliminary analysis of 56 commitfests reveals that 44% of contributors never return after their first patch, 35% of work is never committed, and 47 patches have been stuck for 2+ years — one for 8 years. To ensure PostgreSQL not only survives but flourishes, we need to examine our social infrastructure alongside our technical one. Our rigorous process produced a world-class database, but what do these metrics tell us about contributor experience? In this talk, we present the data and explore possible factors: - Mailing-list workflow vs. modern collaboration expectations - The steep path from "first patch" to regular contributor - Time expectations for volunteers vs. paid developers - Long-term patch ownership and maintenance burden - Review bandwidth and the "Ready for Committer" bottleneck We will also look at how other communities have navigated similar challenges: Perl's decline as a cautionary tale, Linux professionalizing its notoriously hostile culture, and Rust and Django as models for onboarding empathy. The goal is to open a discussion about project sustainability: what can be changed to lower barriers and attract new contributors without compromising our standards for technical excellence?https://www.pgevents.ca/events/pgconfdev2026/schedule/session/635/25-Minute TalkAndreas ScherbaumJimmy Angelakos15:3000:25Labatt (1700)How does PostgreSQL actually handle EXISTS and IN clauses? This talk explores the internals of Semi-Join optimization, comparing the native JOIN_SEMI execution against the strategy of unique-ifying the right-hand side. We will discuss the implications of these strategies on join reordering and query performance. We will also cover some evolutions regarding semi-join planning in recent releases.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/597/25-Minute TalkRichard Guo15:3000:25Canfor (1600)I will describe each of the following aspects of PostgreSQL code. This will include the scenarios in which these modules are used, best practices, detailed usage examples and, where applicable, suggestions for improving their implementation. 1. Resource manager - An in-depth look at the resource management infrastructure, including the ResourceOwner API, lifecycle tracking of various resources, the creation and management of ResownerObjects, and the roles played by transactions and portals. 2. Error handling - A detailed walkthrough of the execution flow when an ERROR, FATAL, or PANIC is raised in PostgreSQL, including how control is transferred and how cleanup is handled. This will include an explanation of START_CRIT_SECTION() - END_CRIT_SECTION() code block, highlighting its purpose and describing error handling from a critical section. 3. Interrupt handling - An explanation of PostgreSQL’s interrupt-handling mechanisms, including the role of CHECK_FOR_INTERRUPTS(). It will also include a discussion on providing a common interface for different types of interrupts as an enhancement to the existing infrastructure. Additionally, I will focus on unifying error handling across process types. This includes analyzing the differences in top-level sigsetjmp implementation among background processes, auxiliary processes, and client backends, and proposing approaches to unify these behaviors.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/684/25-Minute TalkRahila Syed16:0000:25Fletcher (1900)China’s PostgreSQL ecosystem is massive, yet a disconnect remains between its tens of thousands of users and the global development community. As the organizer of HOW 2025 (1,500+ attendees) and PGCONF.Asia, I see a "silent majority" of enterprise users running mission-critical workloads that rarely reach the -hackers mailing list. This 25-minute talk shares technical insights and friction points gathered from large-scale deployments in finance, government, and the world’s largest wind turbine manufacturer. We will discuss: - Real-world Pain Points: Specific challenges in high-velocity IoT ingestion, large-scale partitioning, and Oracle-to-PG migration. - Why We Build Downstream: Why projects like IvorySQL and SynchDB were created to fill gaps in vanilla PostgreSQL's extensibility. - A New Pipeline: How the global community can better integrate feedback from these massive industrial use cases to improve the PostgreSQL core.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/601/25-Minute TalkGrant Zhou16:0000:25Labatt (1700)Accurate join selectivity estimation is one of the longest-standing challenges in query planning. While PostgreSQL's extended statistics — defined via CREATE STATISTICS — improve planner estimates for correlated filters and multi-column predicates, the planner currently applies them only to single-table scans, not to join selectivity estimation. This limitation means that even when the database has information about correlated columns, it still assumes independence across tables during join planning, often resulting in suboptimal join orders and unnecessarily expensive plans. In this talk, I will present a proof-of-concept patch for extending PostgreSQL's statistics framework to joins, focusing on collecting and using join-level MCV (Most Common Value) statistics for common patterns, including but not limited to foreign key joins. The work explores catalog extensions, changes to ANALYZE, and planner-side integration that allow join predicates to benefit from real data distributions of joins rather than independence assumptions. I will focus on evaluating and operationalizing join statistics. Specifically, I will present results on how improved selectivity affects join order decisions, plan quality, and execution-time performance using join-order–sensitive benchmarks. I will also present measurements of the performance cost of collecting join statistics during ANALYZE, and discuss maintenance aspects, including how join statistics interact with VACUUM, when they should be refreshed, and what configurations might be needed.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/689/25-Minute TalkAlexandra Wang16:0000:25Canfor (1600)Extensions are PostgreSQL's superpower—but only if users can actually get them. PGDG ships ~150 packages; over 1,000 exist in the wild. This gap limits PostgreSQL's potential. That's why I spent two years building the pgext.cloud project: a unified, open infrastructure for packaging, indexing, building, and delivering extensions. It now ships 440+ signed Linux-native packages for 14 distros, serves ~1M downloads/month, and maintains PGDG compatibility across 6 major versions—fixing dozens of extension break issues along the way. This talk is for extension authors wanting broader reach, core hackers testing patch compatibility, DBAs tired of compiling from source, and vendors evaluating reusable components. I'll cover: extension statistics and what they reveal about real usage; the architecture—catalog for discovery, repository for delivery, and PIG CLI for easy access; how builds are managed; and how AI tooling helps with packaging and maintenance.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/583/25-Minute TalkRuohang Feng16:3001:00Fletcher (1900)This roundtable retrospective celebrates 30 years of open source PostgreSQL by bringing together project founders and early contributors to reflect on the project’s formative years and its remarkable evolution. Featuring Bruce Momjian, Tom Lane, Thomas Lockhart, Jan Wieck, Vadim Mikheev, and Jolly Chen, the discussion will revisit what the Postgres project was like in its earliest open source incarnation—technically, culturally, and socially. Panelists will share how they each became involved, what motivated them to contribute, and what it was like to turn an academic project into production-ready software with a small, distributed group of volunteers at a time when open source itself was still an experiment. Moderated by Melanie Plageman and Jonathan Katz, the conversation will include behind-the-scenes stories and anecdotes from the early days, including the creation of the mailing lists, design debates, and pivotal moments that shaped the project’s direction. Looking forward from the vantage point of three decades of growth, the panel will also reflect on what they might have done differently, knowing what PostgreSQL would eventually become, and offer insights into how those early decisions continue to influence the project today.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/670/PanelBruce MomjianJan WieckJolly ChenJonathan KatzMelanie PlagemanThomas LockhartTom LaneVadim Mikheev17:3000:20Fletcher (1900)Let's take a group photograph with every available conference attendee. Cement your place in PGConf.dev history!https://www.pgevents.ca/events/pgconfdev2026/schedule/session/508/Other IdeasNoah Misch17:5000:10Fletcher (1900)Let's take a group photograph with every [PostgreSQL Major Contributor](https://www.postgresql.org/community/contributors/) available!https://www.pgevents.ca/events/pgconfdev2026/schedule/session/507/Other IdeasNoah Misch18:1503:00Rogue KitchenThe main social event, sponsored by Microsoft will be held on Wednesday May 20 2026 starting at 18:00 across the street from the conference venue at [Rogue Kitchen & Wetbar - Gastown](https://roguewetbar.com/) located at [601 West Cordova St](https://www.openstreetmap.org/node/2188770960#map=19/49.28539/-123.11141) Vancouver, British Columbia You will need to **bring your conference badge** for admission, food & drinks tickets will be provided.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/713/Other Ideas22:0001:59SWITCHTired: group run Wired: group therapy session aka singing your heart out to any classic rock song really If you would like to join us, please sign up here: [https://forms.gle/otxNWS1XnJ6d4HSC8](https://forms.gle/otxNWS1XnJ6d4HSC8) There is a limit of 25 people.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/580/Other IdeasFloor DreesPeter V Geoghegan08:3001:00Concoursehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/750/Other Ideas09:3000:50Fletcher (1900)You might think that text encoding is a problem that was solved by UTF-8. This is basically true for many developers, but PostgreSQL continues to support dozens of encodings and multi-encoding configurations. There are some rough and even dangerous edges, with implications even if you only use UTF-8. I want to present prototypes to address those with a practical model, and some other opportunities I have spotted along the way. * Overview of the PostgreSQL text encoding model, related OS concepts and motivations * The holes in that model, including shared catalogs and views, authentication, file systems and more * In which usage patterns do we get away with that? Or not? * A proposed model to nail down the encoding of everything, while allowing for reasonable usage patterns * Overview of closely related pg_wchar, holes and improvements * Opportunities to go faster * What would it take to support NUL in text?https://www.pgevents.ca/events/pgconfdev2026/schedule/session/572/50-Minute TalkThomas Munro09:3000:50Labatt (1700)Since its introduction in PostgreSQL 10, logical replication has been continuously evolving, attracting more contributors to enhance its capabilities. As the system expands in size and functionality each year, contributors may face challenges in accurately reviewing or designing new features. Our team has been actively involved in reviewing and developing new logical replication functionality for over 5 years. In this talk, we will share our insights and the knowledge we have gained from writing and reviewing patches for logical decoding, replication, and related DDLs. This session will also include a brief introduction to logical replication. Our goal is to familiarize more developers with its implementation, thereby encouraging more involvement in improving it.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/527/50-Minute TalkHayato KurodaZhijie Hou09:3000:50Canfor (1600)Postgres is famously row-oriented. To achieve analytical performance, most modern approaches introduce Columnar Storage via Table Access Methods (TAMs) or delegate to external formats like Apache Iceberg. But is it possible to achieve columnar speed while remaining entirely within standard Postgres heaps and the shared buffer manager? In this talk, we explore the implementation of a high-performance columnar store built strictly as an **Index Access Method (IAM)** and **Custom Scans**. By bypassing the need for separate storage engines, we gained unique advantages but faced significant architectural constraints. We will dive into the C-and-Rust-level implementation details of `pg_search`, focusing on: - **Execution strategies:** Implementing late materialization for Top-K queries and Joins to minimize tuple reconstruction costs. - **Optimization:** Utilizing dynamic filtering and sideways information passing to push filters down closer to the storage. - **SIMD & Batching:** Techniques used to accelerate columnar access within the standard block storage format. Finally, we will provide a retrospective on the **IAM** and **Custom Scan** APIs. We will discuss specific limitations we encountered, workarounds we engineered, and propose improvements to the API to better support future analytical extensions. This session is designed for extension developers and core contributors interested in the limits of Postgres extensibility.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/682/50-Minute TalkStu Hood10:3000:30Concoursehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/751/Other Ideas11:0000:50Fletcher (1900)PostgreSQL is not typically thought of as an analytical system. Historically, people forked and repackaged PostgreSQL to add analytical capabilities, including native-columnar formats, distributed massively parallel processing, and vectorized query executors. However, these systems significantly deviated from core PostgreSQL and became incompatible with standard PostgreSQL tooling. More recently, several projects have leveraged the PostgreSQL extension system to accelerate OLAP-style queries through federation and integration with DuckDB, but these still lag in scale behind purpose-built analytical systems. One challenge with current approaches for accelerating OLAP queries is limitations imposed by the PostgreSQL architecture, which is better-optimized for OLTP style queries. While several PostgreSQL extensions have added support for a columnar format, the PostgreSQL executor still lacks capabilities required in large scale analytics, including a massive parallel processing and vectorized execution. What if we flip the model on its head: instead of going through the PostgreSQL execution layer, we read data directly from storage? Modern analytics has moved towards lakehouse architectures, which adopt open formats like Parquet for files and Iceberg for tables that are organized and governed by a catalog service. We can borrow these concepts to build a “lakebase,” where we separate storage and compute for operational databases to allow for serverless reads of an open format from different engines. Making it less abstract, think of the PostgreSQL filesystem as an open data format (which it is!) that can be used as a base to build a modern OLAP engine that’s fully-compatible with PostgreSQL transaction semantics that doesn’t require PostgreSQL compute. This allows you to build an engine to run OLAP queries that directly access PostgreSQL data files without impacting performance of operational workloads or requiring additional replicas that are just for analytics. We begin this talk by first outlining the state of analytics of PostgreSQL: how well it works today, what people have done to help accelerate analytical queries through extensions, and some of the ongoing challenges. We then review how the lakehouse works, covering key concepts like open file and table formats, why catalogs matter, and how engines like Spark can leverage these to accelerate performance while still respecting transactional and access control. We then introduce a new open source project that can read PostgreSQL files directly from storage outside of the PostgreSQL process, explain the architecture and the benefits it has for running fast OLAP queries directly on PostgreSQL files through a look at the project internals. Finally, we demo this project using an integration through an OLAP query engine that shows up to 100x faster TPC-H performance on PostgreSQL data without impacting the running PostgreSQL instances!https://www.pgevents.ca/events/pgconfdev2026/schedule/session/573/50-Minute TalkHristo StoyanovJonathan Katz11:0000:50Labatt (1700)What temporal features does Postgres support from SQL:2011, what remains to be done, and what can we imagine beyond the standard? In v18 we got temporal primary keys, unique constraints, and foreign keys. There are patches being reviewed for temporal update/delete. (Maybe by May they will be committed.) With that functionality, foreign keys can support CASCADE/SET NULL/SET DEFAULT. There is a less-mature patch to add PERIODs. System time is also being developed. I'll briefly cover all these features. But there is a lot needed the standard doesn't cover. Most of my talk will discuss what I see missing and how I'd like to approach it: what can core do? What can be an extension? What should we advocate to standarize? A big gap is missing join types (outer join, antijoin, semijoin) and other missing operators (UNION, INTERSECT, EXCEPT, aggregates). If we implement something in core, we need to consider algebraic equivalences and planner transformations for temporal operators. Another big feature is temporal MERGE or ON CONFLICT DO UPDATE: something that updates history while filling in missing gaps. A small thing I'd like to achieve is making all these application-time features extensible enough to work with user-defined types. We are almost there, but it needs something else like a "type support function". I'm also interested in allowing multiple dimensions of application-time: some researchers have proposed using this to model truth claims. An out-of-core extension for multi-dimensional rangetypes could provide this. Patch for temporal update/delete: https://commitfest.postgresql.org/patch/5836/ SQL implementations for missing temporal operators: https://github.com/pjungwir/temporal_opshttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/629/50-Minute TalkPaul Jungwirth11:0000:50Canfor (1600)Over the last decades, many alternative approaches to query optimization have been proposed, including genetic algorithms, machine learning models, neural networks, and reinforcement learning techniques. These methods aim to address limitations of traditional dynamic programming, particularly for join ordering in large and complex queries. The goal of this talk is to critically analyze these approaches rather than promote a single solution. I review genetic algorithms, classical machine learning models, neural-network–based optimizers, and reinforcement learning techniques, discussing where they have shown promising results and where they consistently fail. In this talk, I compare reported results from the literature and, where possible, align experimental evaluations using standard benchmarks. The goal of the talk is to distinguish practical and reproducible techniques from purely research-oriented prototypes, and to clarify what role—if any—these methods can realistically play in industrial database query optimizers.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/683/50-Minute TalkAlena Rybakina11:0000:50Cominco (1415)What's the simplest and least threatening way to get up in front of an audience and talk about Postgres? Join our session, volunteer to get a topic for a one to two minute speech, and have a go. Nobody is prepared, everyone is winging it, and a minute really isn't that much time to fill before you can sit down. Or just join the audience and see a few short talks on three topics. What's repeated in the talks and where every speech differs can be very interesting.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/668/Other IdeasAlastair TurnerFloor Drees12:0000:25Fletcher (1900)Full-text search is table stakes for modern applications, yet Postgres users often face a difficult choice: bolt on Elasticsearch and accept the operational complexity, or settle for Postgres's built-in text search with its limited ranking capabilities. pg_textsearch offers a third path—a permissively licensed Postgres extension that brings production-grade BM25 ranking directly into your database. This talk covers the design and implementation of pg_textsearch, a new open-source extension that implements an LSM-tree-inspired architecture within Postgres's access method framework. We'll explore how the extension manages an in-memory memtable that spills to immutable disk segments, handles concurrent access through Postgres's shared memory primitives, and maintains crash recovery guarantees using only native Postgres storage. Key topics include: - Why BM25 still outperforms simpler ranking functions for keyword search - The challenges of building a write-optimized inverted index inside Postgres - Fieldnorm quantization and block-based storage for memory efficiency - Block-Max WAND for sub-linear top-k retrieval Whether you're considering adding search to your Postgres application or curious about the internals of building a Postgres extension, this talk provides both practical guidance and deep technical insight.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/509/25-Minute TalkTodd J. Green12:0000:25Labatt (1700)PostgreSQL clients have for a long time been able to indicate the hostname to connect to with the sslsni connection parameter, but the server has not considered this at all. Starting with PostgreSQL 19, the server can read the sslsni value making it possible to present certificate and keys per hostname as opposed to a single certificate for the entire server. In this talk we'll go over what TLS SNI is and how it works in PostgreSQL.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/757/25-Minute TalkDaniel Gustafsson12:0000:25Canfor (1600)The end is approaching of the first iteration of an internal program at EDB designed for colleagues keen to become PostgreSQL developers. We'll detail the motivations behind our "Developer U", and our experience with the program. EDB has many people in its ranks not working on developing Postgres code who could with proper training and support become Postgres contributors. This program is designed to provide that training and support. The talk will discuss the structure of the program, and how well it has gone. We'll go into how we started the program, how we recruited participants, and how the program has gone. We'll discuss the challenges of training a group of developers that are spread all over the globe, and that have varying levels of experience with C, and with how the Postgres community operates. We'll share how the curriculum is structured, and share some thoughts on how we can improve the material for the next cohort that is starting in September. Lastly we'll cover how we ensured participants could commit time to their learning and development, while still showing up for their "regular job". This session is for everyone interested in mentoring newcomers to the project, and especially for those in organizations who are interested in developing PostgreSQL talent within their own ranks.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/592/25-Minute TalkAndrew Dunstan12:0001:40Cominco (1415)In this workshop, we will work hands-on in a small group setting to learn how to read and interpret the SQL standard and how to ponder and implement changes. First, an introduction will be given on the different parts and sections and key concepts of the standard. Then, we will take several examples (possibly from mailing list discussions, possibly provided by the participants) and try to to resolve technical and interpretation questions. In the last part, we will try our hands on contemplating and writing change proposals. The goal of this workshop is to enable participants to become themselves redistributors of this knowledge to their collaborators, and to be able to become informed participants on these matters during the development of PostgreSQL. If it turns out someone ends up wanting to join the SQL standards process, that could be a bonus. Participants should be knowledgeable about the SQL language already, and ideally have had some experience in areas such as resolving SQL conformance questions, documenting SQL language features in PostgreSQL, implementing or reviewing patches that implement SQL language features, or working on tools or processes for migrating SQL from other implementations.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/553/WorkshopPeter Eisentraut12:3001:30ConcourseGrab your lunch in the Concourse and bring it to Segal to see the poster session Browse posters online at [https://2026.pgconf.dev/posters](https://2026.pgconf.dev/posters)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/752/Other Ideas14:0000:50Fletcher (1900)Having spent many months in confusion over trying to profile Postgres, and helping other in similarly situations, I now know some of the things that can horribly wrong when profiling and benchmarking. In this talk, I will go through some of the more common and confusing things, so you don't have to develop *all* the same scars. Questions we'll explore include: - How can a substantial optimization lead to benchmarks running substantially slower? - Why can the order in which benchmarks are run matter? - Why will a recently compiled binary often be slower than an older one? - How can the weather influence benchmark results? - Why is it harder to profile virtual machines? - Why can a change that increased the percentage of missed branches improve performance? - Can your SSD suffer from temporary exhaustion? For each of the problems I'll present a way to at least work around the problem.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/594/50-Minute TalkAndres Freund14:0000:50Labatt (1700)PostgreSQL is increasingly used as more than a datastore: it’s becoming an execution environment for AI-adjacent workflows—embedding generation, hybrid retrieval, reranking, moderation checks, enrichment, and policy-aware automation. The attraction is obvious: SQL, transactions, row-level security, and auditable change control. The production reality is also obvious: the first time a database session calls “outside,” we inherit distributed-systems problems inside a system optimized for deterministic local execution. This talk catalogs the most common failure modes we see when teams implement AI workflows around Postgres: • slow/failed external calls from within transactions • retry storms and rate limits causing database-wide degradation • inconsistent writes without idempotency • governance blind spots (which query triggered which external call with what data?) • observability gaps across database ↔ service boundaries We’ll walk through concrete implementation patterns (PL languages, background workers, NOTIFY/LISTEN, queues, extension hooks), then propose a set of patchable primitives that would improve safety and standardization without “adding AI to core”: • an outbound-call abstraction with budgets, circuit breaking, structured retries, and cancellation semantics • an official lineage/tracing hook so external interactions can be tied back to query/user/role • stronger permission boundaries for “show me the internet” capabilities • workload shaping signals (rate control, backpressure, isolation) that operators can reason about The goal is to turn today’s ad-hoc patterns into something repeatable: safer defaults, clearer interfaces, and small steps the community can actually implement.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/590/50-Minute TalkVibhor Kumar14:0000:50Canfor (1600)Postgres has provided an API to build "foreign data wrappers" — extensions that allow queries to execute on external servers — since version 9.3 back in 2011. A [robust collection](https://wiki.postgresql.org/wiki/Foreign_data_wrappers) of "FDWs", as they're commonly called, has developed in the years since, while the API itself has greatly expanded and added features, particularly the ability to "pushdown" execution to the external data source. I come to FDW development with fresh eyes, having inherited the basics from postgres_fdw and clickhouse_fdw to build pg_clickhouse. Now I'd like to share all that I've learned. This session will cover foreign data wrapper basics, query planning and rewriting, and various techniques to increase pushdown. If at the end you leave with a basic idea where to start and how to build or adopt an FDW for your favorite data sources, it will be a success. And so will you.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/510/50-Minute TalkDavid E. Wheeler15:0000:25Fletcher (1900)PostgreSQL’s executor still processes one tuple at a time -- a design inherited from the classic iterator model that favors modularity but adds significant per-tuple overhead on modern CPUs. Each tuple crosses multiple function call and branch boundaries, which limits instruction and cache efficiency even in simple scans. Recent improvements -- opcode-based expression evaluation, scan inlining, and faster tuple deforming -- have reduced overhead in key paths, but the iterator model remains a bottleneck for analytic workloads. This talk presents a prototype that enables executor nodes to operate on batches of tuples instead of individual slots, reducing per-tuple costs while preserving PostgreSQL’s row-based semantics and plan structure. The patch introduces an ExecProcNodeBatch() API and a TupleBatch abstraction for passing groups of tuples between nodes, along with table AM extensions for batch-mode scans. Expression evaluation is adapted to process batches in tight loops, paving the way for more efficient execution over large data sets. The talk will describe the prototype design, early performance results, and outline possible next steps toward broader batch-aware execution in PostgreSQL.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/485/25-Minute TalkAmit Langote15:0000:25Labatt (1700)Although PostgreSQL has hundreds of configuration options, only a tiny percentage are regularly modified in real-world installations, and some defaults are overridden significantly more frequently than the documentation may indicate. In order to comprehend how configuration functions in practice rather than only in theory, we offer a comprehensive examination of PostgreSQL GUC usage across thousands of production servers in this session. We'll investigate queries such as: Which settings differ from their default values the most? Which GUCs are hardly ever touched? What effects do workload type and hardware size have on configuration patterns? What may we infer from the fact that some settings are routinely overridden? Along the way, we'll explain to novices how PostgreSQL configuration actually functions (scope, reload vs. restart, precedence), and then we'll utilize actual data to show common trends, surprises, and hazards. Developers and operators who wish to comprehend not just how PostgreSQL can be configured, but also how it is really configured in production and what that means for future PostgreSQL defaults, performance, and reliability are the target audience for this session.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/608/25-Minute TalkPalak Chaturvedi15:0000:25Canfor (1600)In this talk we'll go into details about how we've extended pg_query, the Postgres parser as a library, to enable new use cases for rewriting Postgres queries. Rewrites are made possible by two components: a Protobuf-based AST representation derived from Postgres raw parse trees, and language bindings that provide convenience functions for walking and modifying the tree. We'll also discuss specific examples of where this is useful, for example to turn certain OR queries into UNIONs or materialize scans on a table. You'll also learn details about the pg_query deparser that supports the complete range of Postgres query syntax (including DDL!), and has an optional format mode that can pretty print the emitted query.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/648/25-Minute TalkKeiko OdaLukas Fittl15:3000:45ConcourseJoins for a slice of cake celebrating the 30'th anniversary of the PostgreSQL project. Cake along with tea and coffee will be served in the concourse.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/714/Other IdeasBruce MomjianGwen Shapira16:1500:25Fletcher (1900)DDL replication is one of the most requested features from users for a long time. While the community agrees on its necessity, the implementation has stalled primarily due to the complexity and maintenance burden of DDL deparsing -- the essential component required to reconstruct SQL from internal representations. In this talk, I'll discuss the specific technical hurdles that blocked previous attempts and a concrete strategy to implement DDL deparsing and replication without imposing an unsustainable maintenance burden on the core team. This is not just a proposal; it is a path forward to deliver the feature users have been waiting for.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/536/25-Minute TalkMasahiko Sawada16:1500:25Labatt (1700)In this talk, I will share my journey from first-time contributor to active PostgreSQL developer. Based on my experience, I will share concrete lessons learned and actionable advice for developers who want to start contributing or become more effective PostgreSQL contributors. The main points of this talk would be: - How I started working on PostgreSQL. - My experience of getting used to PostgreSQL culture. - The challenges I faced, how I overcame them and what helped. - What I would do differently if I had the experience I have now.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/551/25-Minute TalkNazir Bilal Yavuz16:1500:25Canfor (1600)Migrating from Oracle to PostgreSQL seems straightforward on paper - after all, they’re both relational databases, right? This journey reveals unexpected challenges that go far beyond simple syntax changes. This talk shares hard-won lessons from product migrations at Lufthansa Group Business Services, covering some easy wins as well as painful gotchas that can impact performance, correctness, and your sanity. We’ll explore technical nuances that cause real-world problems: Differences in NULL handling and why IS DISTINCT FROM is a distinctly bad idea for your query performance. Numeric types, rounding behaviors, and how to enforce the desired precision. How PostgreSQL’s MVCC architecture fundamentally changes your update strategy - when updating 80 million records in a single query brings your system to its knees. You’ll leave with practical strategies, performance insights, and a realistic understanding of what it takes to successfully migrate from Oracle to PostgreSQL.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/593/25-Minute TalkJoshua SteinmannTino Engelbrecht16:4500:25Fletcher (1900)the cumulative statistics system of PostgreSQL (pgstats) is a vital part of the backend, able to deliver reports made of aggregated information about the state of the cluster. This talk is made of three parts: a light explanation of the architecture of pgstats with its advantages and limitations, a list of the features related to pgstats added to v18, and lastly how extensions can take advantage of pgstats in v18. This talk is aimed at helping intermediate/advanced developers, be it in developing new in-core features or out-of-core modules.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/451/25-Minute TalkMichael Paquier16:4500:25Labatt (1700)Implementing new ideas and concepts in any codebase always carry an element of exploration, Postgres is no exception. A Postgres cluster is a complex machine with many interoperating subsystems, and features that span subsystem boundaries need to understand how these interact, and which states they can be in. Synchronizing state across a distributed system might not be the final frontier, but it is challenging and filled with learning. Sometimes an idea seem so well defined and contained, that it just makes sense. The finish line is almost in sight before firing up the editor. Hacking starts and progress is fast, the first patch is done in mere hours. But, as the surface is scratched and that small corner which was cut in the proof of concept patch is addressed, more corners appear. Then, even more corners lurk in the shadowy depths of the codebase turning the straight path into a winding mountain road. Hours turns to days, days turns to months and.. This talk will use the proposed patchset for enabling data checksums in an online cluster as an example of how a complex patch evolves from the initial proof of concept as the domain is explored and more is learnt. It will discuss what kinds of unexpected architectural and correctness issues we ran into, how to tackle the unknowns, the importance of identifying scope and how to stay motivated as problems mount and time pass. This is not a talk about a failure, but about how embarking on a patch adventure can bring deeper understanding of the system makes us grow as developers and reviewers.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/617/25-Minute TalkDaniel Gustafsson16:4500:25Canfor (1600)Postgres has a high degree of redundancy in its catalogs and backends due to various constraints and design decisions. In previous talks I've gone into some detail on how we can improve memory usage in shared memory, but haven't yet gone into much detail about how we can improve session-level resource usage. In this talk I'll go over some opportunities I've found that -once implemented- could reduce the memory footprint of connections by a healthy margin.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/650/25-Minute TalkMatthias van de Meent17:1501:00Fletcher (1900)A series of short talks, each no longer than five minutes. Lightning talk proposals will be submitted onsite by conference attendees and selected during the conference. Anyone can submit a proposal—whether you’re a seasoned speaker or stepping on stage for the first time. A submission box will be available at the Registration Desk until 5:30 p.m. on Wednesday. Simply drop in a card with your proposal. Selected speakers will be notified shortly afterward. Full instructions will be posted near the box, and cards and pens will be provided.https://www.pgevents.ca/events/pgconfdev2026/schedule/session/705/PanelJeremy SchneiderMasahiko Sawada18:1503:00ConcourseJoin a group of Postgres community folks for dinner and casual chatting on technical or personal topics. Meet new people or reconnect with people you've known for years but haven't had dinner with before. How it works: sign up at the linked Google form; on the day you will receive an email with your group number and leader; meet your leader and group at reception at 17:00; walk together to the restaurant; eat talk and learn; finally pay for your meal and walk home. Note that this dinner is a **self-pay**. More information and [sign-up form here](https://2026.pgconf.dev/attend/social#meet).https://www.pgevents.ca/events/pgconfdev2026/schedule/session/715/Other IdeasPaul Ramsey08:0001:00Concoursehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/753/Other Ideas09:0000:50Fletcher (1900)An unconference is an attendee-driven format where the day’s schedule is created on-site, with an emphasis on discussion and interactive sessions rather than pre-planned talks. The day begins with an organizing session in which participants propose topics, briefly describe them, and collectively build the schedule.. It's a natural extension of the hallway track and a bridge into the new development year. If you feel that your session cannot be productive without a particular conference attendee present, please ask their permission to include them as a "required attendee" for your proposal. The organizers will use this information to minimize scheduling conflicts. Learn more: https://wiki.postgresql.org/wiki/PgConUnconferenceFAQ Add session notes here: https://wiki.postgresql.org/wiki/PGConf.dev_2026_Developer_Unconferencehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/728/Community Discussion - OpenAndres FreundNathan Bossart10:0000:30Concoursehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/754/Other Ideas10:3000:50Fletcher (1900)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/730/Community Discussion - Open10:3000:50Labatt (1700)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/731/Community Discussion - Open10:3000:50Canfor (1600)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/732/Community Discussion - Open11:3000:50Fletcher (1900)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/733/Community Discussion - Open11:3000:50Labatt (1700)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/734/Community Discussion - Open11:3000:50Canfor (1600)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/735/Community Discussion - Open12:3001:00Concoursehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/755/Other Ideas13:3000:50Fletcher (1900)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/736/Community Discussion - Open13:3000:50Labatt (1700)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/737/Community Discussion - Open13:3000:50Canfor (1600)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/738/Community Discussion - Open14:3000:50Fletcher (1900)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/739/Community Discussion - Open14:3000:50Labatt (1700)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/740/Community Discussion - Open14:3000:50Canfor (1600)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/741/Community Discussion - Open15:3000:30Fletcher (1900)https://www.pgevents.ca/events/pgconfdev2026/schedule/session/729/PanelJonathan KatzMelanie Plageman16:0000:30Concoursehttps://www.pgevents.ca/events/pgconfdev2026/schedule/session/756/Other Ideas