Here on file systems, it was fascinating.
It's nine o'clock exactly, so I'm going to hand over to Thomas, who's going to talk about performance
improvements in Postgres for the last 20 years, and hopefully everyone can hear us on the live stream.
Thomas, you might be working?
Yeah, I think it's working fine.
Everyone can hear me?
Cool.
So, hello, welcome to my talk.
I'm Thomas Mondra.
I'm a long-term Postgres contributor, developer, cometer, and at the moment I'm working for Microsoft,
and where I still work on the open source stuff.
But I'm also the first thing I'm a developer.
So, this is a talk about development of Postgres, and looking back over the last 20 years,
of improvements.
The slides are already online on that URL, but that doesn't matter, I think.
If you have any questions during the talk, please ask them right away, because there's going to be,
like, a lot of different topics discussed, so it will just confusing to ask them at the end.
So, just shout during the talk, and I will try to answer that.
This talk is not really something that would teach you how to do new stuff, right?
So, if you are here expecting to learn how to tune Postgres or something like that, that's not going to happen.
So, this is like the rough agenda of this talk.
First, I think I need to explain why I do these talks, because this is not like the first talk of this type that I do,
and it's simply to inform myself, because when you are developing, working on a project for a long time,
you kind of lose the idea how much did it actually improve over a longer period of time,
because we only deal with individual releases.
That's when you probably see, like, you install a new release, and you see, if it improves performance or something like that,
but for level of persistence even worse, because we are only dealing with individual patches.
We are benchmarking individual pieces of code, and, like, how does it exactly does it compose into, like, long-term view?
I have no idea.
So, I did this, these kind of benchmarks, I do them for, to inform myself, right?
I've been asking myself, so, how did the performance of Postgres improve for typical workloads over a longer period of time?
This is the result, right?
I will be talking about two kind of, like, extreme, or, I wouldn't say typical, but extreme cases of workloads.
The first one is, like, really, a transactional OLTP, right?
Small transactions, small transactions, small queries, updates, singularos, something like that.
Chances are your application does something more complicated, right? You are probably, like, loading larger amounts of data or processing larger amounts of data.
It's somewhere on the spectrum between OLTP and OLAP, and OLAP is the second workload that I've been testing benchmarking.
In this case, I've been using, like, a subset of TPCH.
It's a data warehousing benchmark, right?
It's something that runs loads larger amounts of data, like, tens of gigabytes, something like that, in this case,
and runs queries that are aggregating the data and so on.
So, it's, like, much more expensive, each query, it's, like, much more expensive that the queries in OLTP.
And, usually, applications are somewhere in between, right? They do a bit of that, a bit of that, and so on.
So, I will show you how the performance, how the truth put of postgres improved over the years for these two benchmarks,
and then I will also speculate a bit about the future, right, about, like, we saw this behavior in the past.
What's going to happen in the future? What would I, as a developer, expect?
So, well, I already spoke about the motivation.
So, I think it's actually quite tricky question to ask, like, how did the performance change over the longer period of time?
First, because we just don't do the kind of benchmarks that allow, give you a answer, right?
We do, we compare two comments, we may be compared to minor versions or major versions, but never, like, all the versions that want.
You might think that if you are running an application, you will have, like, a better overview.
But that's not really the case, right? Because the applications are not static, right?
You are adding new features to the application.
You are improving the application in various ways, and most importantly, I very much doubt you are still running the application on the hardware that you had, like, 20 years ago, right?
You have done multiple upgrades, which completely, like, change the behavior of the database.
So, this is why I do these benchmarks.
And I think, also, it's not entirely, not only it's tricky question, but it's also not very fair, because if you think about that, then you are developing a piece of software.
You are developing it in the context of the hardware, you have at that time, right?
Like, the first multi-core CPUs came in, like, 2005, right, like, roughly.
And that would, may not be perfectly accurate.
In some cases, I think Spark had, like, more cores before that.
Intel initially started things like hyperfitting, which is not, like, a full core.
But the point is that before, like, 2004, 2005, it didn't really make sense to optimize for, like, multi-core performance, right?
So, no one did that, at least in the post-gres world.
So, now, looking at, like, a software from that time, and benchmarking that using benchmarks that actually require, like, good multi-core, doesn't make much sense.
Well, it's not fair, right?
The other thing is, of course, that post-gres is not living in vacuum, right?
Post-gres is one of the applications running on the operating system.
And there is, like, a lot of things that improve that we rely on, right?
We rely on the kernel, we rely on file systems, we rely on various files of, like, of the system in general.
And all of these things, like, improve significantly.
I'm sure there are talks about these different subsystems.
And those improve, and we are benefiting from that, right?
So, Post-gres relies on the page cache in the kernel.
So, if that became more scalable, we are getting the benefits.
There have been some massive improvements in file systems.
We also automatically get the benefits and so on.
And, of course, like, users do not see those improvements in isolation, right?
You get the new version, new system, with the new kernel, with the new storage, and all of that.
And you see all just the combination of that.
So, I've been trying to kind of, like, isolate just the post-gres bait.
So, I have to warn you, I'm going to present a lot of, like, charts.
I'm not going to show you, like, associates, but I'm going to show you charts that, hopefully, visualize the throughput or, like, the performance.
The short version is, like, it's much faster, right?
Like, if you just want to conclusion the executive summary, this is that.
First, let's talk about all of the, you know, the simple transactional workload.
There is, like, a TPCB.
If you are running, if you are using PGBange with the default workload, this is what you will get.
And I've been, the question was, which hardware to use?
And I do happen to have some machines at home that I use for benchmarking.
They happen to be just in the middle of the, you know, 20 years that I decided to benchmark.
Because the first, first post-gres version that I decided to benchmark is, I think, A.0, which is almost exactly 20 years ago, right?
So, I ended up using a machine, which is, like, roughly in between.
It's not the biggest machine nowadays.
I think it has, like, 4480 or 880 credits.
And, like, 64GB of RAM, some SSDs, current kernel on their VM, and that's it, right?
It's, like, fairly typical machine, nothing terrible.
And the TPCB is, like, a data set, a simple web publication, like, a bank application.
And I'm usually benchmarking three different data sizes, right?
Because, um, if you are familiar with Postgres, you know that there's, like, a shared buffer, which is a cache managed by Postgres.
So, the first sizes, when this, when the data set fits into shared buffers, right?
Um, then there's, like, a medium data set, which fits into RAM, but it's larger than shared buffers.
And then we have, like, a large, which is much larger than available memory, which means it's going to do a lot of IO.
And each of those data set sizes usually hits slightly different different buffal max in the database, right?
Um, the small data set usually hits, like, uh, locking issues, the medium data set usually hits, like, CPU, buffal max.
Uh, and large, usually, like, IO, uh, bucklet.
And then, of course, we have, like, different combinations of parameters, right?
We're on either read only transactions or updates.
Um, you can test with different client counts, right?
It's something different when you run with a single connection and, like, a hundred connections.
And all of them working concurrently.
Uh, I had to do fairly short runs in, like, single digit minutes, because, uh, all of these, uh, combinations.
That's a lot of combinations.
In total, a single run of the benchmark was, like, two weeks, right?
So I just needed to limit the, the, the runs.
Ideally, if you are doing, like, a proper benchmark, it would be, like, multiple checkpoints and all of that.
I had to, uh, you know, compromise on that.
And I did, like, a configuration, which is, like, roughly the same on all the, all the versions, right?
Starting from 80, uh, to the current development version.
Um, so it's a, on new versions, I would probably, I should probably use, like, large-ish head buffers.
On 8.0, 2 gigabytes is the largest that it's actually possible, right?
So, it's a trade-off, right?
It should work reasonably well.
Uh, and, of course, the benchmarking script, the tool, I always use from Postgres 18, right?
Because there was a lot of improvements, even in the benchmarking tool.
And I don't want to be benchmarking that, right?
I want to see the, you know, consistent results.
So, and this is the result of how it looks on the small data set read only.
Um, it's just 1.5 gigabytes, so it fits into shared buffers.
And all these charts that I'm going to show for OLTP look like this.
The different colors, each color is like a fixed client count, right?
It's the same number of clients.
And on, on the X axis is the version of Postgres up to 18, which is, like, that's the current development version.
That's not released yet, right?
And the Y axis, that's true number of transactions per second, right?
And you can see that, like, that's much by the truth put, right?
It's like, we did maybe, I don't know, 100,000 or 50,000 transactions on 8.0.
Now we are doing like a million, right?
So it's like a massive speed up.
Um, this is for simple transactions, a simple mode with prepared statements.
It's like 50% faster, yeah, right?
And that was always the case, mostly.
You can see that we also did some some weird stuff in the past, right?
For example, on 9.2, 9.3, that was actually a regression.
Like a pretty significant one, right?
It's like, I didn't look into what exactly happened here,
but 9.2, 9.3 actually progressed.
There are also cases where you switch to prepared statements.
And it gets slower, right?
These are things that are, right?
In retrospect, it's like, well, we shouldn't have done that.
That's like, that's something that we missed during testing.
But since I think 9.5, where Robert House introduced,
I think, fast-bought looking, which is like a simpler, faster way to lock stuff,
which scales much better.
Since then we are in like really, really good, you know, situation.
I mean, like, it's like almost perfectly stable.
And this is, this is a workload, which is like super simple.
So it's like optimized as much as possible at this point, right?
So this is like the small read only data set.
If you look at like small read, right?
You also see that there are some, you know,
weird stuff happening here.
But again, since roughly, possibly 10,
we are in a really, really like, stable situation.
The same thing is for, like, the pre-closed statement.
So that's good.
If you look at the, you know, read only, I will skip the medium data set size,
because that has almost the same results as the small one in this case.
If you look at the large data set, which is Iow bound, again,
you see some very significant improvements initially.
And then it gets like, mostly stable, right?
There is a bit more jitter here, like, these runs are like,
slower, faster and so on.
That's mostly because the runs were so, so short that it actually didn't even out, right?
The same thing for, for prepare statements.
Also, it doesn't help that much to prepare, to use,
to use prepare statements in this case, because it's Iow bound, right?
So, and prepare statements matter most for, for, for CPU bound queries.
Can you still hear me?
Okay, you didn't break it.
Yeah, okay.
So, do I need to stand in, like, a certain place or?
Okay, I will stay here.
Yeah, okay.
So, this was like, prepare statements, or simple LTP.
But of course, like, LTP or TPCB, this kind of, yeah?
On the private slide, what does that mean?
Yeah, I don't know.
I did look into that.
It might have been somewhat like a hiccup in, in the benchmarking script.
I don't know.
It seems weird.
I agree.
Good.
That you noticed.
Yeah.
Anyway, TPCB is not like the only LTP workload that you can be using, right?
It's a simple, there are no joins for example.
And chances are that if you, even if you have, like, LTP workload,
you are still joining multiple tables.
And quite typical thing is, like, a star join.
Like, star join is usually, if mentioned in the data warehousing,
you know, applications.
But you can actually have star join in LTP,
because you are looking up data in one table and then
enriching the data with, like, additional information from, from other tables,
right?
And that's a star join.
It's like, the fact that you just filter the, the fact table doesn't really change that.
So, I did actually try, like, a star join.
It's a very common pattern, actually, in applications in LTP.
And I did a simple test with, like, a tiny amounts of data,
because you are assuming it's in memory.
And you only have, like, ten, you have, for one table, the main one, the fact.
And then you have, like, ten, do dimension tables, right?
So, it might be a customer info with, like, address and, like,
transaction info and, this kind of stuff.
This is how the query looks like, roughly, right?
A simple join to ten tables.
And it only does 2,000 transactions per second on Postgres.
Like, even on 44 cars.
Let's terrible, right?
The thing is, I've been looking into, like, why this is happening.
And we are just spending so much time on, like, you know,
going through all the possible combinations of the join order,
that, like, ten factorial options right here.
So, that's variable.
And if you, if you just disable, like, prepared statements,
which means you only do the planning once, then the execution is, like,
super, super fast, right?
It's like, you are suddenly getting, like, half a million transactions per second.
And you can actually see the main improvements in scalability on this chart.
Because in 92, we did get the fast spot looking, right?
So, that's a huge jump here.
Then, in working, I'm not sure that was a lot of, like,
improvements of scalability of the MVCC and snapshots and all of that.
So, I don't have a single feature that I could put here.
It's a combination of those.
And then, in 18, I committed an improvement of the fast spot
looking to actually scale to even more funds, you know, relations.
So, in 18, we will get faster again.
But that doesn't change the fact that if you, this only works
if you are using prepare statements, right?
And maybe you can't, right?
That's, the problems with prepare statements and connection
pulling for example, right?
So, the thing is, there are a couple simple hacks that you can do.
For example, you can, you can say, well,
I'm not going to do simple joints.
I'm going to do left joints, right?
And that restricts the possible joint orders a little bit.
And you are not doing, you are not doing, you know,
half a million transactions, but you are doing, like, five times
the original throughput, right, which is good.
There are some other things that you can cue, but really,
this is something we need to fix or improve in Postgres, right?
It's a limitation of the, of the planner.
So, just to give you a brief summary of the OLVP,
there have been some massive improvements in scale building, right?
It's like, and I mean, like, all the of magnitude or more.
Like, we did maybe, I don't know,
50,000 transactions on AWS, we are doing a million transactions now, right?
So, that's really good.
They're having some small regressions in the past,
where something weird happened, right?
Either the throughput decreased with the new major version,
or, like, you did get lower throughput with prepare statements
compared to, you know, full parsing and full planning.
That's really, that's mostly gone since, like, 90.
And I think that's a testament to how much are we testing Postgres,
and also how much we improved, actually,
to develop our processes and, like, how much more careful we are?
This is, like, what could happen in the future?
Like, should you expect other, like, massive growth?
And for me, this is a bit, like, you know, the famous last words,
because every time I make a prediction, like, immediately the next day,
someone sends a patch to the mailing list, proving me wrong, right?
It's like, usually it's undressed, right?
But I think we are kind of, like, out of the low hanging fruit, right?
A big thing's, I don't think there's a change.
That would be, like, a minor fix that results in massive improvements
in throughput.
There are things that we can improve,
but I would expect to be more, like, incremental, right?
We are, like, right now, we are often talking about patches that improve,
for example, my 5%, right?
So, sure, if you do a lot of those,
that could be, like, a significant improvement,
but it's not something that you commit a fast path looking,
and it gets, like, 10 times faster, right?
Yeah.
This was just, like, a simple single number result, right?
It only showed, like, truthwood.
I haven't been showing, like, the consistency of the results.
In the sense that how stable the results are over time, right?
It's, like, you could have, like, very violently jumping results,
and it would give you the same average in the end.
But I think we also got, like, much better in that.
It's much smoother, right?
It's partially because, like, we are just, like, so much faster in,
in the absolute number, that the variation doesn't really matter that much.
So, yeah, I will skip that.
Or the other work that I want to talk about is a lot,
and you can imagine that as, like, a large data set process
in analytical workload, right?
TPCH is, like, a fairly traditional benchmark.
A really simplistic has a lot of flaws,
but also, it's very simple to understand, in fact,
sufficiently good.
So, for this benchmark, I use, like, a much smaller machine,
again, roughly from, like, 20, 10, 15 years ago.
I don't have this machine anymore.
That's, but because I replaced that,
but it had, like, only four cores,
16 year by so far, I am, and so on.
The logic here is that this benchmark is not really about concurrency, right?
It's not about running 100, like, connections at once.
It's about one connection running query,
maybe with parallel workers or something.
So, the number, of course, doesn't really matter.
And also, it doesn't need to be super large amounts of data
to actually show the behavior of aggregations, for example, right?
So, other than that, it's, like,
again, running current debyan,
PhD4 and so on.
And TPCH is a very simple benchmark.
It's very simple to set up, run.
It only has, like, 22 queries that are, like, large,
analytical queries using different different types of, you know,
conditions or aggregations, joins and so on.
And I tested not just this, 22 queries,
but also the initial data load, right?
Because, that also matters.
How fast you can actually load data into Postgres, it's important.
If you are looking for a great paper about PCH,
I highly recommend this, you know,
this paper by Peter Bunch, Tomach, Noiman and Ori Arling.
They are actually looking for, they are looking at individual queries,
and pointing out the bottleneck.
Each query is actually designed to hit,
it's a wonderful paper.
So, the first, let's talk about data loads.
So, these chances will be different, again,
on the X axis is the version of Postgres,
and the P here means parallelism, right?
That means we have enabled parallelism for the application.
Postgres started to support parallel queries,
or like, parallel workers,
and maintenance operations in 9.6,
and then improved, like, I did more,
more support over time,
and on the Y axis is duration in seconds.
And this is, like, the thinking by data set.
So, you can see that there's, like, a huge improvement initially,
and then some smaller improvements here,
where we, you know, optimize how we are doing bulk loading,
and that kind of stuff.
And also, the blue is the initial copy, right?
So, a copy improved significantly here,
and then it remains mostly the same,
because we simply can't really improve the,
the parsing of the CSV or something.
And then the other thing is create index that the yellow one,
you can see that, actually, it improved quite a bit,
even without parsing.
And then, at some point,
we started to support parallel index builds here in 11,
and since then it's mostly stable, right?
So, we have optimized, like, most of the stuff,
and, yeah, it doesn't improve as fast as in the parsing.
If you look at the, at the queries,
this is just a, again,
Y axis is number of seconds,
and this shows, if you run all the queries and some
the durations together, how long it will take, right?
And you can see, again,
massive speed-ups initially, right,
between A and A.2,
I stay at the bottom,
because I'm not too bad.
It's so long ago, it didn't work for me.
But there is, like, a massive improvements here,
and I've been, I've been told that this is probably
supportful bitmap index scans, right?
We didn't have bitmap index scans,
so this probably was,
thanks for that.
Then, in A.4, bitmap index scans
actually started to support perfection, right?
We introduced effective IO concurrency meaning,
like, how fast you can actually
pre-fetch data from, that you will need soon, right?
Kind of, like, asynchronous IO a little bit.
Then we started supporting index on this scan,
again, significant speed up here, right?
And then there are, like, a couple of releases
where the improvements are a bit smaller,
and it's a combination of multiple,
multiple improvements.
And since then, it's, again, mostly stable.
You can see that the, the parallelism helps a bit.
In this case, it actually,
it was a bit slower than here.
But generally, it's quite stable, right?
You will get a good performance
for row or into database here.
I could even show a chart
where the duration is broken by query, right?
Those, like, each color here is, like,
one of those 22 queries into DPCH,
and you can see that initially,
there have been many queries that were, like,
substantial fraction of, of the run.
And most of those actually, you know, disappeared, right?
The only thing that actually remains is the query one,
which is just, like, a huge aggregation of large amounts of data, right?
There are no joints, nothing,
it's just about the row power,
of actually processing data.
Paralism helps, that's very effective in handling that,
but actually to improve that further,
we would need something, like,
columnar, columnar storage with columnar execution,
something like that, which we don't, right?
We are still on, on row store database.
So, I would like to talk about,
I didn't talk about, like, planning before,
but here, I think I need to talk about all app regressions,
because the queries in, in TPCH are more complex, right?
And therefore, that are kind of, like, more susceptible to,
you know, changes in, in the query plan, like,
the queries in TPCB, those are all going to be,
Lukeups by primary key, right, index scans and,
this can't stop.
With, with all app, it's more complicated,
and it's susceptible, not just to mistakes,
but also to changes due to changes in,
in configuration parameters, and how we actually interpret those, right?
So, for example, I wouldn't say that's, like,
a real regression, because that's intentional change,
and the consequence of that.
But, for example, we have increased the,
the value of, effectively, exercise,
which doesn't really mean,
because this is going to use more memory,
it's just, like, information how much data is cached,
which means it's making random IO Luke cheaper,
which means that the database is more likely to pick index scans, right?
And if you are on a system where index,
then random IO is actually not as cheap as the database believes,
this is more likely to lead to regressions, right?
Similarly, effective IO concurrency.
In Postgres 14, we have changed how we interpret
the configuration volume a bit, right?
So suddenly, if you didn't change,
if you just copied the configuration file,
suddenly, the database would perfect,
much less data, right?
And again, if you look into the release notes,
well, it's there, right?
But people do not actually, you know,
it's surprised me, and I'm, I'm,
I'm experienced postgresive operator, right?
And there are some additional improvements
that, of course, can,
there are meant to help the database, right?
If the database knows, for example,
about foreign key relationships during query planning,
that gives it additional information,
but maybe maybe the query plan was by accident,
actually, the world plan was actually faster, right?
That can happen.
And they're probably more.
So I run into a couple of those.
I wouldn't say those are like problems,
like box in Postgres.
Those are, I'm just explaining that it's more like
a limitation of the technology in general, right?
Like, you improve configuration,
and by accident, it breaks something,
like, makes something worse, right?
Sometimes, like, two wrongs are actually better.
So, for all I'm, what's the summary,
and what's the future?
I think, just like for, I think it's,
for the quality of people's runs,
we have seen some significant improvements
over the years.
I mean, like, a zero got prefetching
for bitmapscans.
Nine or two got indexed only scans.
Nine or six got parallelism.
And there are probably some additional
like improvements.
Like, I didn't actually mention like,
uh, parallel index builds here,
um, in Postgres 11, right?
Um, and since Postgres 11,
it's mostly unchanged, right?
Like, there are some small improvements, of course.
I'm not saying that's not the case.
Uh, but for the future,
I would probably expect more, like,
incremental improvements.
Again, people that will optimize individual,
uh, individual operations
to, to get a couple more percent, uh,
of that.
But those are, like, mostly small gains.
I think, uh, we will see some improvements
in, like, a tooling, like,
something that Postgres doesn't change in the code,
but we will, for example, start using, uh,
like, optimization of the binaries.
Like, not just the optimizations built
into Postgres directly,
uh, but, like,
there is PGO, which is profile guided optimization
and bald, which is an optimizer
doing something like that.
Um, and that can actually, uh,
help a lot with data intensive applications.
Um, but I think, for, like, really fundamental
improvements,
we would need to,
to do something,
the analytical databases aren't doing, right?
Postgres is a general purpose database,
which is very capable.
I, I, I love it.
Uh, but still, it's a roaster.
Um, it was kind of, like,
most of the workloads are probably transactional,
uh, like, OLTP.
It can do a lot of analytics,
but it can't really compete with the databases
that have been, you know,
designed for that use case for their workload,
specifically, right?
So we would need to adopt something like column storage
and not just the storage,
but also change the executor, right,
to actually leverage the,
the efficiencies in, in the columnar, uh,
format.
Or maybe in Postgres is, like,
very, very extensible and very flexible.
And we do have a,
a long history of actually,
allowing Postgres to become bind with other databases
or, or some other engines, right?
So, um,
we had foreign data wrappers for a long time,
which just allowed you to interact very,
uh, efficiently with, with other databases.
Or we could develop something completely new,
like, um, to, for example,
I know that there are people working on
DAGDB engine and actually using that
to run queries from Postgres, right?
Um, offloading some of the queries
that can benefit from DAGDB.
And stuff like that.
So, I don't know what is going to happen.
Um, people are, uh,
often have, like, really, really crazy ideas.
Uh, but I think, if we are,
if we are to improve this,
some fundamental change needs not to.
So, to some all of this up,
um, I'm quite happy with, uh,
with improvements in Postgres over 20 years.
I mean, like, it makes me feel good as a developer
that we have achieved that.
Uh, what do I expect in the future,
incremental changes,
but also people, uh,
surprising me with some, you know,
fundamental, massive improvements.
Um, I would like to,
this talk was about performance, right?
About truth put and, like,
some benchmarks,
but I want to make it very clear that
that's not the only thing that makes the database accessible.
All right.
There is a lot of other stuff that actually
matters for users.
Maybe more than just the role performance, right?
It's how easily you can actually operate the stuff.
I mean, like, if you have a database,
which is, like, super fast,
but it's like,
shittons of work to actually keep it running.
You will not do that in production, right?
And we are trying to improve,
um, improve this, uh, all the time.
But let's know what this talk about, right?
So I hope you enjoy this talk.
Uh, well, there are a couple of questions.
Um, this is actually, uh,
the, uh, the question that was already asked.
I don't know what that is.
Uh, would be interesting.
Um, there's an opportunity to optimize, you know,
some special queries.
Like a star join.
I think that might be actually a good, like,
project, all right?
Let's, project how to learn about Postgres.
Uh, there are things that we maybe could use in Postgres,
like, both, which I did actually try on the, uh,
on the OLTP.
And it actually improved, like,
two would by 40%.
Right?
So there's, there's potential.
Uh, yeah.
There's potential.
I, I'm not sure.
I will actually do that in production,
or, like, in builds.
There is plenty of, like, new must have.
Um, under I actually had a,
a really nice talk at PIGICONF EU.
Uh, it's recorded.
It's on YouTube.
So if you want to understand how the database needs to deal with machines,
that have, like, known uniform memory,
which nowadays is everything, like, all the, all the machines have that.
Uh, not just the machines with multiple circuits,
but even just, like, single circuit machines.
Uh, then I think this is a wonderful, uh,
you know, interaction into that topic.
For a lab, uh,
I was surprised that actually the, the optimization of,
of the binaries didn't actually help that much.
I don't know why.
Uh, it might be due to how we do, uh,
evaluation of expressions.
Why?
That might be, uh, incompatible with,
what the optimization is supposed to be doing.
I think a more radical, uh, architecture,
ideas need to be implemented.
Uh, and there are some ways to, to that, like, complex plans,
to confuse the database optimizer a little bit, right?
So I'm not sure.
So there are, uh, slides, links, and so on.
Uh, a couple, uh, couple block posts about this kind of stuff.
Uh, and if you have any questions, I'm happy to answer that.
Either now, or, I think I will be hanging around, uh,
uh, around the booth.
Uh, so.
Thank you very much, Thomas.
So we've got a little bit of time for Q&A.
Uh, the format of Q&A, if you can shout out your question,
and Thomas, the people on line,
because the, if you shout out the question in the room,
we're all here.
It's, but unfortunately, the microphone, what, the,
the people on line works.
So Thomas is going to repeat the question summarise it.
So, uh, would you?
So, TPC has a board to take process.
Are there any vendors or other vendors to still go through that?
I have no idea.
Uh, we didn't repeat the question much.
Yeah, okay.
So, um, the question is like, uh, whether any process,
when and the vendors are going through the TPC, um, auditing,
because both the TPCH and TPCB,
those are actually, um,
clearly specified and a require that if you want to use those results,
uh, you need to go through the TPC organization
and make actually audited like the results, right?
You are not supposed to just run benchmarks and,
and, uh, publish the results on your own, right?
I don't know if anyone is still doing that.
Um, it kind of, I don't know.
And for me, it wasn't my intention to, to get anything like that,
because it's fairly expensive process, right?
It's like a long thing.
So, and I don't need audited results for my own use, right?
So, I don't know.
I haven't seen, for a long time,
I haven't seen any vendor, like, you know,
uh, in marketing materials to showing like,
oh, we have this number, right?
Um, I think the,
that was probably more relevant in, in,
in times of, uh, like, on-premise databases and, like,
like, systems developed, uh, and, uh,
provided as, uh, as a complete solution, right?
Because, you know,
the vendors will,
they'll, they're giving you the database,
but also the hardware and everything,
all the services around it.
So, it made sense to kind of like,
and have, like, a stamp of, of the performance.
Um,
I don't think people are doing that now,
because people are just, you know,
taking a piece from there,
running that on, on the cloud provider of their,
uh, choice,
and I don't think, uh,
it's very relevant, anyway.
Thank you.
Any more questions?
Hello. Hello.
Uh, hello.
Uh, so question is about migration and updates,
regarding AWS.
Current veterans, for example,
13.14, uh,
have updates, uh,
global updates in AWS, uh,
and we will move all our data.
Uh, for example,
Chef used external post-greSQL,
and, uh,
will this migration pass smoothly?
Uh,
I mean, if Chef already in releases,
says that it's used 13.18 version,
like, okay.
And, uh,
AWS says that all versions from 14
will be updated to 18.
So, uh,
should I make any tests
before, uh,
make this migration on product?
Um,
I'm not sure.
I understood the question,
the sound is really bad here.
But, um,
let me try, uh,
to answer what I think is a question.
Like,
when you are upgrading and, uh,
Postgres,
the,
um,
it should be either compatible.
You don't need to export import anything.
Uh,
and there's, uh,
a tool which is called PG upgrade
that you can use to, you know,
transfer the catalogs, right?
We haven't changed the,
we've already changed the catalogs.
So,
the data files are still the same,
and you shouldn't mean,
and they like,
copy out,
copy in, or anything like that.
So, was, was the answer for the version?
Yeah.
Um,
I think it's short.
I mean, like,
Postgres has a lot of testing,
exactly for, like, PG upgrade.
Sorry.
Yeah.
Sorry.
Postgres has a lot of, like,
testing for upgrade.
Uh,
cases.
I mean, like,
it can break.
Um,
I have no doubt about that.
But, uh,
it shouldn't, right?
We do our best to make sure that
it's reliable.
And, uh,
I haven't seen a PG upgrade, like,
failure for a long time.
All right.
I mean, like,
usually it's not because of Postgres,
but it's because of, um,
like, a problem in the operating system, right?
Um,
like, using link mode in cases where
that's not possible and stuff like that.
So,
I'm like,
if you run into an issue,
please report it.
Um,
and that's, and we will fix it.
But, um,
that's about that.
Thank you.
Any more questions,
but he could, maybe at the back.
Yeah.
Put a hand up.
Shout.
Really shout out.
Yeah.
Right.
So, right.
So, into the PG benchmark.
So to the question is that in the,
the PG benchmark,
here.
The, the, the one,
one,
a client.
Um,
line is like,
almost.
Uh,
almost like flat person.
It doesn't improve, right?
It's a very simple benchmark, so the per client per client throughput didn't improve that much.
Actually, it'll be grasped a little bit.
But it's not visible here, but most of the improvements are really about concurrency,
about handling, like, locking between sessions and so on, like more efficiently,
those are most of the improvements.
Yes.
Thank you.
We have time for just one more question.
We have to finish at 9.50 exactly.
I believe.
So any more questions?
Okay.
Maybe I can give you one minute of your time, extra back.
Thank you very much Thomas.
That was really interesting.