Firefly2024-03-142024-03-141https://www.postgresql.eu/events/pgdayparis2024/schedule/08:3000:30Otherhttps://www.postgresql.eu/events/pgdayparis2024/schedule/session/5419/Breaks09:0000:10Auditoriumhttps://www.postgresql.eu/events/pgdayparis2024/schedule/session/5423/Open/Close09:1500:45AuditoriumIf you are a newcomer to PostgreSQL or want to be more active within the community you need to understand how the community works, what different roles are, where to look for help and who stands behind the “PostgreSQL community”. This talk will provide an overview of: * different roles within the community, communication channels where one can look for help, conferences and events; * user groups - How to start a user group? What are the steps for having a successful meetups? What are some challenges and where to get support?; * postgres development - commitfest, roles and responsibilities and the overall process. Presentation will have references to other talks, guides and materials that dive deeper into specific processes within the community. It can be served as a toolbox for anyone who is looking to join and contribute to further development of The World's Most Advanced Open Source Relational Database.https://www.postgresql.eu/events/pgdayparis2024/schedule/session/5293/TalksValeria Kaplan10:0000:20Otherhttps://www.postgresql.eu/events/pgdayparis2024/schedule/session/5420/Breaks10:2000:45AuditoriumThe sustainable collection of performance data from database systems for flexible and extensive evaluations through snapshots and reports are available from commercial database manufacturers and a essential and a popular feature for several DBAs. There is also a suitable solution for PostgreSQL with the extension PG_PROFILE. This talk describes the requirements and basic setup of PG_PROFILE and shows with examples and practical experiences how this can be used for proceeding performance analytics.https://www.postgresql.eu/events/pgdayparis2024/schedule/session/5067/TalksDirk Krautschick10:2000:45LouxorA tech talk delivered by a total newbie to the PostgreSQL world. This beginner talk will look at how to make PostgreSQL relevant to people whose main line of thinking may not be technological. PostgreSQL is awesome - we can probably all agree on that. But how do the non-techies among us learn to understand and appreciate it? How do we understand how it can be used so that we can become evangelists even though we can’t build the databases ourselves? This beginner talk will look at the first, second, and third normal forms of a normalized database, and will include an explanation of why "The Key, the Whole Key, and Nothing but the Key, so Help me Codd" is a critical component in this field. Differentiating it from other such proposals, this session will be delivered by a technology newbie with a focus on helping true database newbies to understand, use, and even appreciate database normalization. After this talk, participants will be able to answer the following questions: what are the first three normal forms of a normalized database? Why does it matter? And where do I go from here?https://www.postgresql.eu/events/pgdayparis2024/schedule/session/5320/TalksEliza Bennett11:1500:45AuditoriumPostgreSQL depends on the local file system for various consistency and persistence guarantees. However, in the Cloud where local disks are ephemeral, you'll have to look for other solutions. Network-attached disks (like EBS) are one way to persist data in a cloud environment, but at Neon we decided to disaggregate storage and compute, and get rid of the local file system entirely for long-term data storage. This talk discusses the technical challenges we encountered at Neon while building a disaggregated storage and compute project based on a PostgreSQL fork: the problems that we encountered, the solutions we built for them, and the benefits we get from disaggregating storage and compute.https://www.postgresql.eu/events/pgdayparis2024/schedule/session/5347/TalksMatthias van de Meent11:1500:45LouxorThe community is unanimous, `PostgreSQL` become the `Linux` of the database, for the sake of all 🚀! And this because this Database engine has some fantastic features to solve complex problems very simply! <img src="https://link.davinkevin.fr/pgfeatures-cover" alt="drawing" width="200"/> Come to discover in this presentation the most useful tricks to avoid you having to code everything from scratch in your app 😅 We will detail standard features of the SQL world that are not well-known, as well as PG-specific features that make it an exciting SQL engine 🔥. And finally, we will explore available PostgreSQL "distributions", because in this field, there are plenty of choices, whether it's for on-premises or scalable in the cloud ☁️.https://www.postgresql.eu/events/pgdayparis2024/schedule/session/5221/TalksKevin Davin12:0001:30Otherhttps://www.postgresql.eu/events/pgdayparis2024/schedule/session/5421/Breaks13:3000:45Auditorium13:30 **Claire Giordano** Fighting the Butterflies & giving your first Postgres conference talk 13:35 **Léo Unbekandt** Deploying thousands of PostgreSQL Clusters - High-Level Architecture of a DBaaS 13:40 **Karen Jex** You Don't Need a Database Backup Policy 13:45 **Chris Ellis** Electric Elephants 13:50 **Matt Cornillon** Discover your favorite cheeses using Postgres and AI 13:55 **Michael Christofides** BUFFERS by default 14:00 **Floor Drees** That's a nice Postgres you have there, would be a shame if you were to lose ithttps://www.postgresql.eu/events/pgdayparis2024/schedule/session/5425/Talks14:2500:45AuditoriumIn the great SaaS world we live in now, we see more and more multi-tenant systems. When it's not too late to weigh in the design of the database for these setups, you face several options. Choose wisely, there will be no turning back. After working for about 10 years as a more or less official DBA in several companies, I have faced several implementations of multi-tenant databases, and seen several benefits and drawbacks of them. In this presentation, I would like thus to give an introduction to what multi-tenant databases are, how they can be implemented, and how they can come back haunt you. This talk will include, but not limited to: - patches that had to be written for PG to work around the drawbacks of some choices (and because, if I dare say, PostgreSQL is not perfect), - how lonely you can feel when many PG tools are made unusable, - mathematically proven optimization pain, - some humor to lighten things up.https://www.postgresql.eu/events/pgdayparis2024/schedule/session/5040/TalksPierre Ducroquet14:2500:45LouxorIn our experience, when developers create partitioned tables, they will create a few partitions to cover the first year, create a few more after the year and finally forget about them. Abandoned partitioned tables are a big risk for the stability of the system. Worst case the application tries to insert data in a table where no partition is present to hold the data and the application throws an error. But also not cleaning up old partitions might cause performance problems in the end. We have created a system where we force the developers to create a contract for their table whenever they create a partitioned table. This contract consists of the name of the table and a json field. The json field provides us with unambiguous specifications that are still very flexible. Since we store the contract in a json field, we also talk about the json data format, how to use it and why we have chosen it for this use case. The same can be accomplished with YAML. We will shortly touch on this example as well. By forcing the developers to create a contract about their partitioned tables we automatically create a discussion before the partitioned table gets created. These discussions often lead to a clear definition of table partitioning, better understanding for developers, review of the election of the partition key, less ambiguity, better collaboration between developer and DBA, easier to maintain partitioned tables, less friction between teams and, most importantly, more Friday events with devs and DBAs together.https://www.postgresql.eu/events/pgdayparis2024/schedule/session/5170/TalksBoriss MejiasDerk van Veen15:1000:20Otherhttps://www.postgresql.eu/events/pgdayparis2024/schedule/session/5422/Breaks15:3000:45AuditoriumA long time ago in a galaxy far, far away, a group of adventures went into a deep dark cave on a distant planet to find a famous Prophet and ask him Important Questions. The Prophet listened, took some time, then answered that their database is going to do 3k IOPS. While still mostly in the area of science fiction, the idea of predicting how the database is going to behave under certain conditions is very attractive. In this talk we discuss possible approaches for modelling, taking a simplified PostgreSQL index under a load as an example -- and try to simulate and verify the resulting IO profile. This journey will bring us to many places, going as high as building a mathematical model, and as low as figuring out how BTree page split is working.https://www.postgresql.eu/events/pgdayparis2024/schedule/session/5298/TalksDmitry Dolgov15:3000:45LouxorMany of us, both Devs and DBAs, may have spent most of our careers working traditional storage engines i.e. b-tree or b+trees. However over the last decade with the growing popularity of cloud scale (very large and distributed) databases there are many new alternatives, some of which are growing in popularity. On the postgresql.org wiki there is a “Future Of Storage” page (https://wiki.postgresql.org/wiki/Future_of_storage). I’m pretty excited about columnar storage and lsm-trees. Columnar storage tech has been in data warehouses for a while and is now available as a regular extension, available in the postgres community edition. While there are some limitations with this extension, they are not too difficult to understand and well documented. I want to give a quick demo of Columnar storage use cases and potential gotchas. While the concepts of columnar storage are relatively intuitive, LSM trees work and behave fundamentally very differently from B-trees and this can lead to some really surprising behavior. Devs can still use regular SQL commands, but the performance can go from very good to very bad, based on the “use case”. LSM tree storage is also available in the community postgres edition via foreign data wrappers. I want to give a slightly longer demo of some of the more surprising behavior i.e. to highlight one of the pitfalls of working with LSM trees and possible application design changes for Devs. Aim of this talk is not to go in depth into database storage internal structures, rather to give a general overview of both b-tree and lsm-tree storage principles. Plus to help both Devs & DBAs with design and debugging as they start working with Columnar storage and LSM-trees.https://www.postgresql.eu/events/pgdayparis2024/schedule/session/5294/TalksDave Pitts16:2500:50AuditoriumThis session will describe one of the Postgres 16 new feature related to logical decoding: Logical decoding on standby. We will see: - the challenges that have been faced during the implementation - how the challenges have been addressed - this new feature in action (live demo) with use cases We will also see what is currently missing to provide "transparent" logical replication slot failover from primary to standby (and what we currently have at our disposal, with live demo, to synchronize logical replication slot from primary to standby).https://www.postgresql.eu/events/pgdayparis2024/schedule/session/5122/TalksBertrand Drouvot16:2500:50LouxorThis talk is prepared as a bunch of slides, where each slide describes a really bad way people can screw up their PostgreSQL database and provides a weight - how frequently I saw that kind of problem. Right before the talk I will reshuffle the deck to draw ten random slides and explain you why such practices are bad and how to avoid running into them.https://www.postgresql.eu/events/pgdayparis2024/schedule/session/5333/TalksIlya Kosmodemiansky17:1500:15Auditoriumhttps://www.postgresql.eu/events/pgdayparis2024/schedule/session/5424/Open/Close