There we go. I'll let you do it. Yeah, we can just roll it because it was like super long. That's good. Where's my other mic? Right here. Number two. You screwed it all up, man!

She had it all nicely set up for you. For us. Okay, we're going to have two microphones. You're going to need to hold both. You need both because... Yeah, there's two different... One is for people to hear and one is to record.

So... Yes. Check, check, check, check. Alright, Magnus, you want to go ahead and set up? Alright, everyone, we're about ready to start the lightning talks, I think. It's going to be slightly hectic, but you know what? That's how lightning talks go.

I think it'll be fun. First up, we have Yuri from Fujitsu. Here you go. Go ahead and grab those. You need both of them? You need both of those. So try to talk into both of them. Yes, there you go. And here you go. You're welcome to go ahead and come up and use the laptop. You're ready to go.

Okay. Hello, everyone. I'm Yuri Enomoto. I'm working for Fujitsu Limited. He's Arul from Australia. Because I was a poor English speaker, so I asked him to support.

And I would like to introduce about Fujitsu database appliance product based on Postgres GL. So the name is ATA database ready, called HADR for short. Anyway, shall I start?

Fujitsu developed the ATA DR for mission critical system. Why do we choose Postgres GL as database for mission critical system? So here is the answer. This chart is a performance measurement of version 9.3 by PGEcons.

PGEcons is Postgres Enterprise Consortium in Japan. As you know, the TPS improved in proportion to the CPU core number.

So Postgres GL has high reliability feature and also has high performance feature. And therefore, this is the reason why we chose Postgres GL for HADR.

So this black box is HADR. HADR has two points. First point is open standard. We use 100% pure Postgres GL and implement additional function as plug-in to avoid major change to core source code.

And another point is Fujitsu's integration technology with hardware and software.

So we provide HADR in optimal state for... Sorry.

We provide HADR in state full hardware redundancy configuration and software operational design. Therefore, it is easy for anyone to operate a setup and operate.

So without tuning, even mission critical system. In this picture, my colleague is making a replacement of hardware. This is hardware specification details.

When you open the front cover, you can see server and network switch is duplicated. So database server is duplicated by Postgres GL streaming replication and backup to storage.

Also, we are available as SSD to avoid IO bottlenecks. If I have enough time, I would like to introduce Postgres GL performance by SSD later.

In this way, HADR achieve high reliability and high performance of Postgres GL. So next, I would like to explain about software. We provide appliance manager. So appliance manager integrate software and hardware.

So this can monitor all of hardware OS and Postgres GL. So when database was stopped, appliance manager identify where failure is. And user receives a solution for the issue on the screen.

So user only clicks the recovery button. So appliance manager select a solution from these three scenarios. So, I'm sorry, so please direct to collaborate with community more.

Thank you. So thank you very much.

All right. My name is Mark, but I'm here helping this guy out with a presentation today.

As a crochet elephant from Portland, Oregon, for you Portlandia fans.

So today, checked in, asked to do a lightning talk. Asked Tom if he could submit a patch.

Keep trying, maybe next year. So he has a tumbler to see what his cousin's been doing. He's looking for a new home. See if you can pick him up at the charity auction tomorrow. Thank you.

Next was an online one.

All right. My name is David, and I want to kill middleware. I have been working with integrating, how do I do this?

Right arrow. Right arrow. I've been working with integrating some kind of database stuff and web applications for about 20 years now. And to say that, it seems ridiculous, but yes, it's been that long. So we have data storage, we have rendering, and we've got this thing in the middle.

And what it's done in the past is it's done HTTP request handling, database connectivity, data manipulation, business logic, HTML creation, and it sends it back and forth. And we've got something talking to the database and HTTP and HTML in the back. That was the old days. Today, what we have is we have a variety of front ends that you can't see because it's too dark.

HTML rendering, data manipulation, business logic, and HTML creation are all on the front end now. The back end, we've got data storage. We still have that, but we have data manipulation, we have business logic, and in the middle, all we have is HTTP request handling and database connectivity.

That's what we have now, okay? But what we can have with the advent of Postgres 9.2 and above is we can have all those things that are in the database plus the JSON type, and if we add HTTP request handling in there, we get this magic situation where we get to bypass everything in the middle

and ask the question, what is it for? So this is what I want, okay? I have a demo of this working. I created an extension using the GNU open source HTTP request handling.

I created that extension. It runs as a part of the database, accepting JSON and running stored procedures that are described as a JSON request. It returns JSON back to the browser. It works perfectly.

If anybody would like to see it or would like to contribute or like to just know more about this, please come and see me after. Thank you. If you like people who are quick, thank you.

That's the whole point, right? So I don't know why that's not working. Who's up next? You're up next. Do you have slides? It's another one. What am I doing? It's an online one? Yeah. Okay, right. So where is your online one? I sent the URL.

The URL. Not that one. I suppose. Where did you send it to? The light. Oh, that's Dan's thing. Can you find it? Okay, yes. Cool.

Small intermission. Static. You know what? The other guy gave me a URL on a little note here.

You failed. Try again. Yeah, you're going to need to type a top-level domain, I think. Or, you know, .com or .something, I imagine.

Oh, yeah. You need a dot, dude. There you go. Period. Right here. Where is it? Right here. Right there. Static. There you go.

Keep going over to the right. Enter. Yay! Oi! Oi! Do you need anything else? Or is that good? Thank you. There you go. Okay. Hi, I'm Renaud. I work for Dalibault, a French progressional company. I think you may have gotten the French part yet.

I'm here to talk to you about my latest pet project, PG-QuallStats. So, what is it about? It's an extension which will collect statistics about predicates. It's really similar to PG-Stats statements. It works the same.

In fact, most of the code was ripped off of PG-Stats statements. And it's available on PGXN as a testing release because it's not been tested extensively right now. So, what does it do? It's installed as a planner hook and it will look in pass query for statement on the form

some colon, some operator, some other colon or some colon, some operator, some constant or something like that. And then you can query statistics about this. What is it good for? Ah, it doesn't render correctly. What is it good for? It can help you find which of your columns

you're requesting against the most frequently. And the next logical step is to suggest missing indices based on those statistics. So, if you're always querying one colon with another, you will need a composite index on both those columns, et cetera, et cetera.

So, it's an index advisor. The next step to this is to be able to suggest partial indexes by looking up commonly used constants and why not suggest foreign keys when columns are frequently joined together.

So, if you have some time or some will to test it to ensure it doesn't crash your backend or have some use for it, please meet me or contribute. Thank you.

Who's up next? VDR? Okay. All right. PDF is here. Wait. VDR or Hall stats?

Oh, right. That's right. Yeah, because you were right. Ah, wrong thing. There you go. There's a mic. Please make sure you keep speaking into the mics. Hello, hello. All right. My name is Mark Sloan. I'm here to talk to you about what is called BDR

or bi-directional replication. It's a upcoming, we hope, extension in Postgres. About two years ago, apologies for everyone who's probably heard this now five times in the last two days.

About two years ago, we saw a need within Postgres that we didn't have by we. I'll talk about that later. But bi-directional replication is basically built off of what is now everyone knows as streaming replication. We had a specific need for WAN replication

around being a multi-master. There are some other products out there that do multi-master that are tightly coupled nodes. But we kind of needed something that was going to span the globe. Another thing that BDR can do is filter replication. So this is filtered at the database level.

Right now, if you do streaming rep, you get everything in the instance, as most people are probably aware. Another goal was easy, or at least we wanted it to look easy. So what does it look like? As I said, it looks a lot like streaming replication does right now. Unfortunately, to get it, you still have to recompile. But basically, you tweak your PostgreSQL Conf

to preload some libraries. You set up some connections, and that is per database. And then you go. So who's working on this? I would like to say thank you to Second Quadrant. They're doing pretty much all of the development work.

Intel Security is where I work. That's formerly McAfee. We're helping with some funding and a little QA work. Docs, so they're on the wiki for PostgreSQL.org. It is totally open. Everybody can use it.

It's being donated back to PGDG, anything that we produce. Same with documentation and everything like that. There are several pieces of the framework that have come out of this that other people look like they're using for things that we hadn't even originally intended, which I think is some of the point of giving back to the community.

All right, that's all I got.

Here you go. Please make sure you keep the mics up close to your mouth. Hello? There's your time right over there. Okay, cool.

Hey, it's Ozgun from Cytostata. And at Cytostata, we're building a scalable PostgreSQL that scales to dozens or hundreds of machines. Today I'm going to talk about the Columnar Store. We open source the Columnar Store. Out of curiosity, how many of you have heard of what a Columnar Store is? Like half, maybe 10, 20 percent?

At a very high level, it's basically instead of storing data row by row, you're storing it, laying it out column by column. And this is an extension that we released. It's a foreign data wrapper about a month back. And when we were building it, we didn't want to build it from scratch. We looked around, and there was this open source specification out there

which was called the RC file, optimized RC file format that came out of Facebook a couple of years ago. And basically the first version, the RC file version was when they were laying out their data, let's say you have 100 million rows and three columns, column A, column B, column C. The idea was they put like one million column As

followed by one million column Bs, followed by one million column Cs, and then another million column As. They published the specification on ICDE, I believe, and it picked up, particularly on the Hadoop world of things. It's out there. They also have some performance comparisons on the published paper.

About two years later, they developed a second generation of it, so that's to optimize RC file format. It's basically, again, a specification. And the optimizations they've done on the RC file format were lightweight indexes, min-max indexes, and enabling different compression methods. So this is, again, out there on the internet. If you're interested, please go and take a look.

We basically picked that up, and we made it a foreign data wrapper that integrates nicely into PostgreSQL. So all you need to do is create the extension, create the table, and then start running your queries. So this is niceness one, which is table compression ratios. Again, this is on TPCH, which isn't the ideal benchmark because most of our customers who are looking into using this are,

they typically have hundreds of columns, and you'll look into this when you're bottlenecked on IO. But again, 10, 20 columns, integers, big integers, numeric types, dates, so it's basically there. And the RC file format basically compresses in groups of 10K.

In here, you see the compression ratios in the benchmark, more or less three to four X. So depending on your use case, this could effectively increase your memory utilization. If your workload is in memory, if you're using SSDs, you get nice bang for the buck because your SSD storage effectively increases. And also if you're on rotational disks or on SSDs,

you benefit from reading fewer data over your disk throughput, like three to four X, and may grow if it's integers up to 10X, 15X. So that's the compression ratios. They are normalized to one. The line item table here is the biggest table. That's that slide, and this is the other slide, which again using the TPCH benchmark,

which is not again the ideal benchmark here because for most of our customers, they have hundreds of columns, and then their queries are only picking a few. But then again, this is on an EC2 instance, on a rotational disk. And I'll open up parentheses here, just like because it's important. In here, we're saturating the entire disk bandwidth, but we're only using one CPU core.

So we're running these queries sequentially, so the disk bandwidth is saturated, but the CPU, we have other CPU cores that we're not utilizing. And the benefits are, again looking into here, more or less about 2X. The benefits depend a whole lot on the query itself. All queries where PostgreSQL isn't bottlenecked by CPU,

such as query number six, C store provides bigger benefits because then you're reading fewer chunks of data, like only the columns you're interested in, and the compressed data from disk. On other queries where it takes PostgreSQL longer to execute, say query number three in the TPCH benchmark,

the benefit is relatively smallish. But then again, there is a benefit, particularly when you're bottlenecked on disk IO. And then those are the three slides that I have.

So this talk is called begat, or the mother of all databases.

In the beginning, all was darkness and chaos upon the deep, and all was null and void, and we didn't even know if null was equal to anything or not. And then came EF-COD, and he said,

let there be light. And there was light. And it was the first day. And then came Michael Stonebreaker, and Michael Stonebreaker begat Ingress, and that was the first generation. And then Michael Stonebreaker begat Postgres, and that was the second generation. And then Michael Stonebreaker ran off

and begat a whole bunch of other things that we don't really care about, except that most of them seem to have a little piece of Postgres in them, if you've tried any of them. But we're more concerned with the generations of Postgres. So Postgres begat Illustra. And Illustra was eaten by Informix,

which was eaten by IBM. And that was the third generation. And Postgres begat MSQL, and MSQL begat this thing called MySQL, which I don't think anybody uses anymore, but I thought I'd mention it. And Postgres begat Postgres 95,

and Postgres 95 begat PostgresQL. And that was the fifth generation. And early Postgres was quite fecund, and begat many things, including GreatBridge and NewSphere UltraSQL,

my favorite name, and Paragress and Red Hat Database and Mammoth PostgresQL, none of which, unfortunately, are with us anymore. And Postgres also begat Pervasive Postgres and EnterpriseDB. One of these is still with us. Can you guess which one?

And PostgresQL begat Pgcluster and Pgcluster2. Those aren't with us anymore. So then we begat PostgresXC, and PostgresXC begat StormDB, and StormDB begat PostgresXL. And PostgresQL also begat TelegraphCQ,

and TelegraphCQ begat Truviso. And Postgres begat PostgresR, and PostgresR begat Translatus. And then Postgres entered the realm of data warehousing, and begat many things. It begat Netezza, and it begat Bisgeres,

and Bisgeres begat Greenplum, and PostgresQL begat Astrodata, and PostgresQL begat Paraxel, and Paraxel begat... Goodness, Amazon Redshift. But we are not done in the realm of data warehousing, because PostgresQL had a brief fling with Hadoop, and begat HadoopDB,

which begat Hadapt, and also it begat Yahoo Everest, and begat Citus Data. And here you can see the family and the many generations of PostgresQL. Truly, it is the mother of all databases.

Right next to your mouth.

Don't try to... Just hold them. Just hold them. One of them is for recording, one of them is for the... Got it. And then right arrow to go. Ready? Your time is over here. All right, so I'll talk about one of the begats here,

PostgresXL. Yet another Postgres-related cluster. Begat from XC. There's some code there. There's other parts that are different. The planner and executor are actually fairly different. So it has some same properties, like cluster at MVCC, ACID, all that.

But it adds in data node to data node direct communication, and MPP parallelism, while also being write scalable. It does allow you to scale out. There was a TPCH slide earlier. This is kind of outdated, but it does give you nice performance boost for TPCH type of workloads.

And also, so earlier someone presented about a columnar storage engine. It should be pretty easy for us to adapt that in, so we should be able to get the benefits of MPP parallelism and compression, so we could probably shrink these another two, three, four times, whatever the benefit was on the other one. So I'm excited to take a look at that

and integrate that in down the road. How it looks when you create tables, you specify a distribution key. In this case, I'm distributing on that. What plans look like would be, if you're joining on the respective join columns, it's going to send this plan to both data nodes in this example, and it's basically going to push it down both nodes

to do a local hash join, and it's going to basically merge those results. Now let's take a different case, where we're doing a join. One column is on the hash distribute column, another one on the other table, it's not. It's going to similarly send down a plan to each data node, but when it executes one part of that tree,

it knows, oh, I need to hash on column two and send it over to the other node so it can join with column three. So we try to parallelize the plans as much as possible and make it an MPP architecture, so kind of an open source green plum type thing.

So we do have some differences compared to Postgres XC, like performance. The multi-tenant security as well, we try to lock that down. PT database, PT user, you can't take a look at that. You can only see your own information. If someone's motivated and wants to pull that out and put it into Postgres, feel free. We also collect additional statistics.

In terms of the project, we want to emphasize stability and bug fixes over adding new features so that people feel comfortable that their data is safe. And because it is a scale-out cluster, focus on performance. And we want to be a very inclusive community, so if people want to participate in roadmap discussions

or priorities, we want it to be driven by the users. So we want to be inclusive, encourage you to get involved. I was in the XC project also from the beginning,

so as my final slide, I'd like to ask Koichi Suzuki of NTT if he'd be interested in being a co-project lead on Postgres XL and working on that project. Thank you.

All right. I'm knocking on the mic because I'm just loud. I assume everybody can hear me okay. I just wanted to bring up a couple of final notes regarding the party tonight. So basically what I'm going to do is I'm going to bring it up over here so people can see it.

If you are not familiar with it, this is how you use the website. Yay, website. Hey, who was in one of these talks? Yay, like five people. Thank you. You all are great. All right, here's the social event. It's a major social event. It's at Johnny McBeauties. This, at least according to my Googling and looking around,

it looks like it's right across from Lesweets. If people are not familiar with that, you can find it on Google. Make sure that you bring your badge because the badge is a very important thing. Magnus is timing me on this lovely lightning talk that I have going on here, which means I think I am going to go ahead and mic up because you know what? I have four minutes to talk to you.

I like talking. Have you noticed? Has anybody noticed that I like talking? I talk all the freaking time. Okay, all right. Have fun. I want to see everybody at the party tonight. It will be a blast. There is cake at reception. There is cake at reception. I have been told it is probably all gone,

but you are welcome to go try it. It was somebody's birthday. Does anybody know who? Who? Brides. Wait, what? Dubaius. Dubaius. Do we have a Dubaius in the room? Maybe he is eating cake or celebrating or whatever. I was going to have us sing Happy Birthday.

I have another three minutes here, but he is not here, so I am not going to put you all through that, I suppose. All right, go to the pub or wherever Johnny McBeauty's is. I guess it is a pub or something. Trust me, there will be alcohol. Everybody will have lots of fun. Good night.