Well, good afternoon, and please welcome Strik Viln, Vilname, Vilname, I'm sorry.
And he will talk about stats, baby stats roll.
That's very rock, right?
Please join me.
Okay, hello, for us then, very happy to be here, and to make it a perfect solution for me today,
my laptop managed to get some failures, so I have no keyboard.
And so it was like a little bit stressful just before I have to replay things, and I hope
the website and everything will be okay, so I'm sorry, Vilname, but apparently I'm missing
the bottom of the slide already, so, well, it's supposed to be a bottom, I hope
wasn't exactly the work, but so I'm sorry, I'm sorry, I'm not involved in the progress
well long time, nearly 20 years, I started working on a full-text search online when I was in
a web industry, and so I was involved in GSAW, and then I found it's a conference in France
and in the 15 years ago, which has been a re-name, and we've earned it at that early
four years ago, and so I'm not a CEO, President of Data Bene, and Data Bene is a service provider
for the security and site to data, and we're providing many services, as many people, many
restrictions, maybe for Data Bene, that we are not a software editor, we do only open source
of hardware, so we are not a sensing, we are not selling license or anything, just providing
services, and assistance, and trying to make you use the security and ecosystem the best
way you can, and we are doing and running around here in software and also starting new
project for our, and we are in, so the main point today we'll be to talk about the
process here at 18 new things with statistics, and we will start by presenting what
there was a cumulative statistic at the moment, is that already required, what's the importance
for the security, and brief history, review of what happened on doing the equations, and
some open question already at this point, and then how it works, and there's a wood in
a C part, and so how we can use what's going to be possible in a possible 18, so at the
end of the year, so you can write your own extension to manage your own statistics and
metrics inside of the security, but using the potential n-rine to manage that for you.
So cumulative statistics, you said, it was very, probably very correct at the beginning,
but today, this is not absolutely all the view, but there is in the documentation of
the SQL page, informing you of the functions and view, which are related to cumulative
statistics, and so at the moment, there are many view, you probably know, if you're
already used for the SQL, which are PG Stat activity, for instance, which is in this
page, but it's maybe not really cumulative statistics still.
We have replication, we have stuff for SSL, we have stuff for Baron Rite, for check
point, right, for many things that cover it, and PG PG PG, and line is very rich, I mean,
they often people ask how to get information in PG and very often just offered directly
by the system, not everything, but there is a lot, a lot of views and functions to get
a lot of information about what's happening on the Indian line.
So, in order to get some example, I hope it's really good for you, but so the first
view, first to act, it's just a view from the checkpointer, so Pitches that checkpointer
in particular, which is a way to be informed about what is doing the checkpointer, or
many time it has been started, triggered by timer, because you consume all space, what
was the time writing, duration, and so on, okay? So clearly, this part is a community
view, because you see it in a time, every time you have a new checkpoint, you make a
plus one, and plus one, you increment, and you increase. If you consume time to write
stuff, and you keep on causing more time, so the right time is going to increase of a
time. This is expected. Just under, this is a much larger one, which is Pitches that
you use your tables. This one is a little bit different, because this is a lot of cumulative
statistics, but the use of tables are very important for the school and system tables
overall, and so many of the information here are drawing with information that we
grab when we are working on a table. I mean, when we're planning the query and we're
doing things, we get from information, and from the same place, we can move from
to the school and the table and the same table. So here, for example, you see that
is a interesting line here. We tell you that there is one million rows in the table,
but then if you go there, there is no delete note, there is nothing, but still the
live purpose are not one million, because this one information is not true. This is just
an estimation of what's inside, okay, we'll get back to this point. So cumulative
statistics and set system, it's not always exactly what you may think it is really
aware. And in order to get some more example, the Pitches that activities that you probably
know, this is the top-like for the school, so we're just joining with a PID of your
process and informing you of bootware and new back-and-started what they're doing and so on.
And you even have new view like this one where you're able to track what's going on.
You're earning a create index or you're earning a vacuum or some operation. You have a
views which are going to inform you where are you in this process, at what stage of
the creation of the index you are and what's going on. So this is cumulative, but just
for me, just to look at some activity at a point in time and then it's flush and the view
will be empty on the index creation has been completed. So, on those you, many are way
how cumulative statistics, so community statistics, it's really just a counter and you
increment. Okay, but there is a special one, I mentioned, Pitches that all tables, which is
also Pitches that all tables, system tables and user tables. This is the same thing, all
is everything and then you have view to just look at a system of just look at user
tables. So, except it's one which is very special, all the
view mentioned in just cumulative statistics as usual. Okay, and then we have all the views which
are more about activity and joining statistics, cumulative statistics and also current activity.
What's going on? And then we have a lot, much more new, which are only about current activity.
So, this is cumulative statistics in the documentation, but in fact, it's not always
cumulative statistics, just monitoring information, ongoing information and we keep all
the gaps in the name that was introduced in Portugal maybe 30 years ago and which maybe
is not a great anymore. I want to talk to much about that, but there are also many
functions, because all the views, others use and so what I do is that for each field,
each attribute, which goes going to call function, which is in the C function, which is
going to provide the value to put in the view. So, views are just a collection of functions
and other would. There are more functions than the views, because we have functions with
statistics to clean the cache of stats and some few functions which are going to be added
during political 18. And so, the first thing I believe which is super important to understand
is that we have also data statistics in political, this is super important, the data statistics
is what's inside your tables, inside your columns. So, this is what is used by political
to evaluate the distribution of the data and to ensure that you make a good choice when
you do an in-exclan or sequential scan and what's where. But those are user statistics,
user data and it's very confusing because the name is the same. So, it's PG stats and
PG statistics, but it's not what we are talking about today. And for memory, I put two
part for users and for systems, because by default, political have the machine access to
those statistics. But when a user want to look at the statistics that has been produced
by analyze, we use the view for users. So, we respect the fact that this user is granted
to access this data. It's respecting the grant and we work of each user as they can access.
So, first thing that I'm really tempted to push on the word matrix which is maybe more
accurate today would what we use to do on my drink system both use. And so, matrix are not
to weight. It's not absolutely true. There should be free weight, but they are not as confidential
as free weight as statistics are. And so, there is a big distinction here. And so, the
communicative statistics allows you to get inside, inside of would say and line, I'm
getting dashboard, getting fancy matrix, a boot squatting on, no buff in saturion and so on.
Okay? One, maybe key aspect for today that there is many service providers for writing
position on the cloud. And I'm very, I mean, you know, as you and so on, but also on private
cloud, I mean, for example, for the scenario with also managing its own cloud, there
also need to provide information for users of the online. But there is the extension
between being able to provide monitoring information and getting access to that database
and access data. And so, the monitoring and the communicative statistics is very, very
a way to segregate between what we can access and what we cannot access when we do monitoring.
That's a very big important point. And so, the matrix for those service providers, especially
in the cloud area, are very important. Probably that it has justified, so many activities
of four last years in this area. And matrix are essentially, if you want to get a good view
on what going on in this system, if you want to discover problems, you don't have a button
neck and so on or debug, matrix like those are very, very interesting. So it's just a summary.
And so, as I said today, we're going to talk about this part. So, communicative statistics
are like matrix, and there are not too close to impact how close the school is working.
It's behavior, but it's not always true. This is true for 99% of the data we have, but only for
that. And as I said, communicative statistics can be information about ongoing activity.
And there are not really directly impacting the school behavior, but still, it will be interested
by that because, for example, for replication purpose, when you want to do a switch over
or fail over, you may want to fail over to the replica, which is the most advanced to the
replication stream. And so, to be aware that you look at those stats. The many big things
is very far out of our room, the boring point I will say. Out of our room is a process
we're going to do maintenance on your database, on your tables, running and lies,
and on your vacuum. And this is triggered by a number of rules, which has been
modified, inserted, deleted, and so on. And those information are coming from the
critical, cumulative statistics system. So there is nothing else because if you visit
the stats, it will come on fork. This is created right in the documentation of the
school. This is a warning from the doc of the school. Using PC stat Reset, also with
a computer that the computer can use to determine when to trigger a document on an
a lies. With the things the screen tells can cause otherwise come to not pay for
this sidewalk, which can cause problems such as table blood or outdated table statistics.
How? The tab as the word, analyze, recommended after statistics, I've been
visited. Okay. So it means that when you restore your database, usually
after PC restore, you run and analyze because of that. If you reset your stats, you
still need to run and analyze. Running and analyze on one gigabytes of data or
one terabyte of data or ten gigabytes of data is not the same story. And so maybe
what was acceptable before is not acceptable anymore. Because sometimes we need to
reset start to get a better view on system because the workload has changed
over time. And so you have two big numbers. It's not interesting. It's not moving
well for you. So you want to reset the start. But if your database is very large,
you're going to impact your database a lot. So getting split here will be probably
very interesting. I've got a brief story about what I've planned on doing
the so-and-use in the school in the server. So the big change has been in
in the school 15. Because before the school 15, the statistics were on a file.
So it means that each 50 minutes a month or I don't remember exactly it was just
rushing to file. So you add this down stats term directory and you pack
a and then you copy and you pack a and you copy. And for Windows user, it was
one of the first boring things because Windows user add to move the stats
time directory in a RAM drive in order to get something which was
efficient. And it was not very robust. And also it required to delay
the amount when you can access the information. Because you cannot get the
new stats until it has been flushed to disk. So it wasn't very big
things to move that from the file system to the memory only. And so it has been
run and possibly 15. And so we fortunately we dropped this one, which is
actually nice. But we added this one that nobody knows. And this one
parameter here, stats based on C, is the parameter which is going to
inform when you connect. If a new session you're going to require statistics,
what are you going to do with the stats? Do you want to get fresh
stats every time? So every time you get the number of
insert in the table, you get back to the main memory and get the
information for each get. Or at the first time that you get this
information for this table, you keep it in cache in your local
section. Or as soon as you start using stats, you grab all
the cache from the main memory to your back end. And the three are
interesting. The first one where you fetch every time is very
interesting for monitoring systems. Because it means that you can
be connected on the processure with your monitor and just get
the stats and you know it's fresh that every time because it's coming from the main memory.
No problem. The second one is very interesting and this is a default
it's called cache. Because when we plan the query or when we do
processing, in particular we want
stable statistics at one point. When you're planning a
join between tables and simple, it will be the same table at several times.
We don't want the stats to change as we're planning the query.
And the last one. But I'm not sure exactly what the very
piece of it. But it exists. So you get all the cache, all the stats
locally. Be aware that the number of stats are very
changed over time. And years ago we had maybe 10 or 20
kilobytes of stats. So getting a full copy was very
not a problem. Today, with what we have in political
17. And next, a risk political 18, we have statistics
per table, per back end, and a lot of for IO, far
racing. And currently, if you're one million
tables, you're one gigabyte of stats associated with
this one million tables. So it means that if you have
selected fetch consistency to grab everything, every time you
connect something, you have one gigabyte of memory back in your
back end. So you connect 10 back end, and you can
send 10 gigabyte. There is no copy on the right
of whatever. So be careful of this one.
So we're improving on after that much more. I mean,
starting with the fact that stats are in my way, we are very
free to do more things. It's much more efficient. And some
kind of add more stats, and using more effectively. So
there were a lot of interest, facility for IO, which was very
super important to get more information. IO in
particular, has always been a pain. Be aware, I am
waiting for memory, or I am waiting for the system, or
from this, or I would not want to take to get this
this buffer field and so on. So getting views on IO
is very interesting, and so you should step forward, and
also consuming memory. And there are also attributes.
I need to pitch that tables, pitch that indexes, to get
a lot of information about the last index, or the last
access to logic. It's interesting if my index has not been
accessed since maybe one year. Maybe it's safe to
get that this index is not really required to accept
it for a constraint. So it helps the operation and
DBA to discover, use an unused object in your
online. In postcards, I don't list everything because
well, it's not supposed to be. Postcards 17, we had
it, which was already presenting in a big
variety of view, but we split both. So it's clear.
This is a background right of postcards, or this is a
background, track point of postcards, and get
distant statistics, distant information. So for
operation, it's very efficient, very much more easier than
before, and much more interesting also. And
events that increase number of statistics, we also
increase the way we want to use that statistics. At the
beginning, we had only one big function, just
reset everything. And after that, we start saying
no, no, we cannot reset everything every time, we
just want to reset some chat catalogs or just some
local statistics. Time for exam, and in postcards
17, it has been proved to be able to reset very
just small part of your stats. So you do not have to
analyze every time. And in postcards 17, I believe
this one was very interesting, which is started
about reporting with the progress on a
person. Back home was a little bit before I
think, but as index processing and use maintenance,
because always a question you're creating an index, and
you don't know when you're going to end. With those
view, you have a view of where it is, and you
can evaluate how much work it remains to do.
So, here, I want you to put what has been
I did so far in postcards 18, but it's moving a lot.
When I say it's moving a lot, I prepare those slides at
the beginning of January. And basically, I have to read
right part of them because it has been time. And I
is ongoing commit. More or less, I believe the more
important thing is that in postcards 18, so here is my
slide. In postcards 18, we are going to have a tracking of
stats for pairback and for many things. So instead of getting
for example information about the world stats system, a
wall did you consume overall. You will be able to know
how much wall you consume on this back end. You
can use this action, this operation. And this will be
valid for a lot of things. So starting with next
version, we will have more tools to be able to
profile the your session and your activity.
It also first, what is currently committed. It also
first to get session tracking, we already have
transaction tracking so far. But here's a new
commit, which are included. Put everything in the
system to make it much more easier and future to
add new stats and to be able to fine tune what you
want. Okay. This slide was just to outline the
three main problem we have, which is that
details, number of insights in the back
room and number of modifications in the
system, which are used by the
person. Other than that, not a lot of single
critical. Also, it's called
administrative statistics, but in fact,
sometimes it's just a go. So it's not
communicative, sometimes it's just not a
go to a go. So again, we just use what was in
pace, keeps the same wording, same name, but
the use that has changed over time. So I
believe for next version, if we're
interesting to align here and get
information in the documentation to
better outline what is statistics, what is
committed, what is the goge, what is
activity. So my open question for
developers of the school and
committers. Because in
the school 18, you will be able to write
your own extension to manage your own
statistics. So the statistics, which is
in memory and which is internal to
the school at the moment, we will be
also with an API in the future.
Starting with that, it means that people
are going to do the development, and so
it will be very hard to change
function name, view names, or even
a lot of things. So I will be
before the school 18 is released.
We need to ensure that what we have
makes sense in the future, and that we do not
make the same design mistakes that we made
some years ago when we were thinking
because of the help of I, or that
the number of blocks changing was
enough, and we realize that no, it's
not enough, we need to know the
bytes, which has been modified, which is
this time. So we are adapting.
So my point is to try to remove
this piece of that view at all, because
piece of stats and piece statistics are
user data, and we have something with
similar name, which is something distinct.
So let's remain in, maybe we need
piece of metrics, or piece of metrics, or
whatever name, which is very clear,
this is not a user stats.
And also the point of
boots, auto vacuum, and the number of
tupper in the table.
Years ago, maybe a decade ago,
it has been a really long discussion about
how to accurately report
the number of four in the table, and how to
accurately report the number of
insert and so on.
And it had lead it to new
algorithm into possession field, and
when you run analyze and vacuum,
it's going to re-epaluate the number of
fours in your tables every time, and
reduce that.
It was very important.
I'm not sure it's so much
important today, because before the
numbers were not stable,
they were not quite safe, they
were not very good.
Today, we are able to have
stats with the notion of
create, transactional, and
what transactional.
So it means that we can prepare
stats, but if there is a rollback,
we also rollback the stats, and
so that that we may
inaccurate.
And so maybe there is a point
here to try to re-work
his part, and to use more
transactional information, to
figure what is the number of
tuppers, which has been
to then start auto vacuum.
So how does that work?
Starting in the C code more here.
We use shared memory to keep
shared stats.
So shared memory is easy.
This is a nice place in
RAM, that many process can access,
and get information from it,
or modify it, if there is a lock.
And we have locked memory to
a community statistics.
So in particular, you know, it is
only forks.
So when you have a new connection,
you create a new forks.
This is your backhand, and this backhand
is going to be able to a community
statistics and information.
And at some point, given some
condition, maybe there is
another transaction, maybe a
timeout, maybe a direct
function call or whatever.
These local stats are going to be
merged or flushed into the shared memory,
and so other people will access
it also.
And the other point is that
we have statistics
persistence on disk.
As a moment, statistics are
persisted when we shut down
the school.
If I'm not wrong,
maybe there are ongoing work
also to flush part of the
start doing checkpoint, but I
didn't follow up here,
and I'm not absolutely sure.
But that, the shared memory
local memory is a flush
and the start persistence makes
all the system very robust and very
also robust for concurrency.
Because this is local to the backhand,
you can manage the stats very
freely without impacting other users.
The only moment where there is concurrency
and is when you merge your local
stats with the main memory.
So if we go into the C-part for
extension developer, this is probably
why you want to go to be able
to write your own extension to manage
your own statistics for your application,
your device or system or whatsoever.
At the end of the stats system from
for the school,
it's not as easy to complain the same way
as the tables and the time tables are,
but it's probably much more than enough
to many metrics that you use
to have for your application.
So maybe in the future,
instead of getting counters in your tables,
you will have counters in the stats system,
which is much, much, much more efficient.
So basically,
that you have C-parts,
pgstat.c,
pgstat functions,
which are going to provide
all the basic infrastructure.
And you have then pgstat,
underscore something for all
the kind of statistics that you're going
to manage.
Table, function, database,
background writer,
check font writer and so on.
And then we have iris here,
which are the most important.
The first thing is that pgstat internal
is also for external process.
So it's not really internal.
This was internal,
but this is either that you want to include
when you write an end condition
and you want to manage that.
Okay?
Because if you include pgstat internal,
you grab everything you need to write your extension.
So in those three,
the rest you have definition about
all the API structure that you have by default
and the function that you have by default.
Okay?
And the new file appear very recently,
which is pgstat kind,
which is going to describe what kind
of statistics you have in the system.
Okay?
And,
dumb.
Yes, this one.
What? Sorry.
Sorry.
Starts kind.
I go on a little off the other side.
So the structure that you want to use
when you write your extension,
to manage that are very easy to understand.
After all, it's very simple system.
There is one first structure that you're going
to use to store your metrics.
You have free to do whatever you want.
It's better for a bit of stick to the pgstat
counter type, which is provided by a particular,
but you can use other data type.
Like Boolean, Joacking, Tegger, or whatever.
Okay?
So in this pgstat,
start from country that we have an example.
This is the one used by for the scale for managing
the function's call.
How many times this function has been called?
How much time spent executing this function?
Set time.
I'm global time, including the ship course.
So this structure will be used to store statistics.
And this one will be used by possess
to be able to get where your statistics are
and to access it.
Okay?
So the first more less opaque while the second is very important
and we don't need to manage this one.
Sometimes it's interesting to add new members to this structure,
but the default one is very valid for most statistics.
Okay? And this is entry point for your local statistics.
And then we have a pgstat entry ref,
which is a generic structure to manipulate your stats.
And so for possessual what he knows that there is no entry ref.
In the entry of the pending entries,
there is a current entry, there is a number of pending list actions
in those that and they will use that.
So the concept of kind,
this is a list that you can find in pgstat.sh.
And so here the first part here,
which are viable number of objects.
So this is a kind database,
relation, functions,
replications, replication slot,
subscription and backends.
All of that you can have several.
It's not just one row.
You will have one row,
a one entry for each of your databases,
relation and so on.
So it's a viable number of objects that you have to manage
to the stats system.
In position, on the channel memory,
there is a good algorithm which is going to scale up the memory
and to increase the size of the decay to stats
as when you increase the number of relation,
or when you increase the number of databases,
and you need more room.
This is managed by possessure itself.
You don't have to do anything.
And there is another part,
which is a good fixed number.
So here this is often just for a single process.
I'll try to go back on writer,
check pointer and so on.
So you know,
there is as many numbers of row and no more.
This is fixed attribute,
a little bit more efficient maybe,
but after all for us as a user,
it's very similar.
What you will change for accession developers,
that's a function callback that we will see after that,
another same,
if you manage variables statistics of fixed number of statistics.
And so the thing for possessure ageing is here,
is that in possessure ageing,
we can create new stats.
Registrate to the system,
and possessure is going to manage that for us.
So in summary,
we have global chart memory,
we have local backend only memory,
and we have a callback when we create new stats,
and we say auto merge data for my local memory,
to my main memory.
How to read that the information is back,
and what some few callback like this one.
We also have some look,
to manage cashing and snapshotting of the stats,
as I saw before,
the stats page consumption, for example.
And this notion of local backend only memory,
and global memory,
if you're looking at that for my money,
to write a point of view from a telemetry point of view,
immediately you will discover that
that there is notion about synchronous or asynchronous metric.
And if you are dating directly,
the share memory is a global one,
this is synchronous metric probably,
or at least you are able to provide some single synchronous.
But if you go through the local backend only,
this asynchronous metric.
So if you use an open telemetry,
for example,
this distinction is very pertinent,
and it's reset here.
It also means that when you are going to manage
your own extension, your own stats,
you have this observable part,
which is local to the backend,
and you have this share stats on memory.
And the observable part,
you can work on it.
Maybe you are communicating information,
and you can process it before merging with the main memory.
That's a lot of thing to do in this era.
One point here also.
The stats in polystyrene are managed by just three by 2D.
The Tabas of ID, object is on T4.
So if it's a new valid one,
it means that the stats are shared on the cluster.
If there is a Tabas ID defined,
this is only for the Tabas in this database.
And then there is an object,
OID.
Before it was an ID,
because before we had stats only for object impossible.
But today we have also stats for backends.
And backends do not have an object ID,
they have a PID.
So the object ID here can be,
for example, PID,
or real OID,
or whatever you want to do with it.
On the other point,
that for the scale is then going to use
key of these structures,
the global structure,
to reference your stats,
and to access it quickly.
So what I'm describing here is correct,
it's true.
But it's going for a bit of change
a bit before physical 18 is released.
Okay.
But more or less, the ID and the concept is true,
we may.
So finally,
stats for extension.
This is an example based on a Pax,
Pax is a particular administrative statistics.
It's just simple extension for physical 18,
which is going to provide new conters,
means you go to Instagram and so on.
So instead of writing your own extension
to manage the new extagram or gore,
you may use Pax,
at least to get the Idders.
And so you already get all the API
to create misuse,
go to conters and Instagrams,
and that you can use in your own extension
to do your own resipe with that.
So here's a simple example with a misuse,
so we are just creating a new stat.
We call it misuse,
and you see the first part is a local one,
so you are defined everything I want.
I just have a single pointer called misuse.
And there is a boiler placed structure for all misuse.
So this one is going to be the placeholder,
I will say, for the first one.
Okay.
If you,
this is a simple result.
If you want more conters,
you can add more conters in the first structure,
and you go.
Then,
if you have defined those two structures,
or you misuse,
you need to register the system into possessual.
Okay.
So for that,
you will need to load it in child memory,
library, and so on.
But more important in the code,
you will have this Pitchy stat kind of
for structure which is provided by possessual,
with strict number of members,
and with members to declare
the name of your new stat.
And if it's a viable number of objects,
or fixed number of objects,
so it's visible,
available,
because we manage the memory,
and increase memory as needed.
You can define if it's a course,
as all the tabases or pair the tabases,
which make me realize that I said something wrong before,
because the database of the ID,
which we saw just before,
can be invalid also in a non-share database.
And something which is very recent,
you can also define if you want to statistic to be right into disk,
because maybe it's not interesting,
maybe you want to start only for live activity,
because there is no point in trying to flesh that to disk.
So in order to not aflashing at the end,
when you restart or stop at a square,
you can define right to find the force,
and here you are.
So I did not list all the members,
but what I really was the most important to understand,
what is the simplest way and the easiest way
to get your own extension.
So as usual, you just need to inform
about the sizing of your data.
You created a new institute with members with a new view,
so what is the size of his structure?
And what is the offset to this stats member?
Remember, the stats number is on the shelves,
the global structure,
and this is what the school is going to use to find your stats.
So you just give it the offset to the member,
and boom, you go to it.
And then you have some callback that you can define.
For example, reset time stamp.
By default, on the stats, you do not have a reset time stamp.
This is global information.
When did you last reset to the stats?
But if you want to be able to reset statistics
for each row of each stats,
you can do that,
and you can add a new member in the structure
to keep information about the stats,
timestamp,
and also provide the callback functions
to inform political what he must do to reset the stats.
Not to reset pattern.
What he must do to register
the last time you reset statistics.
There are two members, two say here as name,
and formula is name, which are not interesting for me,
yet at the moment,
but which are using political further applications lot.
You know, when you have a application certain political,
you connect the back end,
but this application is not as a name.
It does not have an object idea whatsoever.
So the way to follow up here is to use the name,
and so we have for callback functions,
we are able to move from string to a key to a string,
and which is used for application set,
and maybe for future extension.
The panic size here is also interesting
because if panic size is defined as zero,
there is no panic entries.
So you're walking only on the main memory.
There is no local memory.
If you define the panic size,
you can have just one structure,
but you can do whatever you want.
This is to manage your panic list,
and your panic statistic,
that you want to push later.
And then you define a function.
It has callback to flesh.
It means to merge the statistic from your local back end to the main memory.
It looks like it's a bit boring,
but if you just write those few callback functions,
your system is going to work.
For instance, this is what you need to have in the call.
You need to define.
You need more,
firstly, when the protocol is starting,
it's going to load module coming from chat,
but load device parameter,
and so you add your extension or your module to this list,
and so it's going to execute PG in it of your module.
When it's going to execute PG in it,
you can register your new kind of statistics.
Okay? Easy.
But only doing startup.
And then you just have to define,
okay, when I want to flush statistic from my back end to main memory,
what do I do?
I get the panic entries,
and I get the style start,
and I say,
okay, the shell statistics of my measure,
it just plus the local measure.
So if I have 10 in main memory,
and I'm already at 5,
then it's 5, 15,
and I have that measured memory.
That's all.
But if you want to do something else,
you can do something else.
If you want to do at the same time,
a mean, a max, average,
rates, ratio, whatsoever you want to do,
when it's pushing, you can even say,
okay, but here, example,
I increment in my value 10 times,
in 20 minutes,
maybe I can, I want to register that,
I can,
I can use that to produce aggregate of
frequency rates in my main memory.
Reset times times is very easy.
There's a callback function,
and so you just say, okay,
what is the member in mass structure,
which is holding the timestamp of my last visit.
That's all.
And now we need to use it.
So in this first example,
this is an increment,
which is not only on the main memory,
on child memory directly.
We bypass the local memory here,
because we are directly asking to get a lock
on the entry ref in the child memory.
And so we lock it,
and so we can work with it.
So this update here,
update the measure,
is done directly in the child memory,
and visible for everyone,
as soon as this function has ended.
Okay?
Why?
And so you notice here,
that BGDL export which allows
to get this function exported to another model,
another extension,
which means that if you want to use measure
and increment to measure,
instead of writing again this new
this function,
you can just use it in your own code.
But if you want to go in the pending entry,
it means that you're going to increase the
measurement not globally,
not on child memory directly,
but on the local back end.
There is also a function for ID by processual,
which is going to prepare for you,
room for this data.
So this function is going to manage,
there's a structure exist,
as we declare the size is okay,
and so you can start using it.
And then,
just after here you recover,
you get your entry, you're planning entry,
and so you can do a measure plus plus,
so you can manage your but only locally here.
So it's visible locally,
it's not visible in the main memory.
And then,
it gets me,
because you want to get the value at some point.
And see,
it's very similar also,
except that I decided to add a function
to say,
I want the local value of the global value.
And so bad on that,
you get the local also remote value.
So it means at the same time,
you have only one measure,
but already has two points of existence
and two distinct value possible.
If you go on a scale,
you have that.
Notice that I do a big in at the beginning,
okay, this is transaction.
So an action has a point here,
because when you are inside transaction,
by default,
it's not going to snapshot and two pattern.
By default, it's not going to flash your start.
You're in transaction,
and often the stats are flush in memory
at the end of the transaction.
So I put a big in,
and I increment for them,
this is a new pointer.
And so I have one.
You see,
if I select,
get me a pending true,
I get this one,
which is a local value,
I get zero on the shell start.
But then,
I come and my transaction,
so it's going to do a commit or a walk back,
according to the previous mistake.
So here's going to commit.
And when it has committed,
my get me from the main memory,
because then it's forced,
as been updated,
and my local memory has been flushed,
and it's zero today.
Okay?
Very easy to get one measure,
with two possible pointers inside,
between my local activity,
and the main memory.
If you want to go more on the topics,
you can improve your structure,
and you get a measure,
is your main max,
right, everything.
If you want to walk with these programs,
not a problem.
Here, I use a fixed number of,
an array with a fixed number.
And honestly,
I'm not sure that we can use a fixed number,
with this part,
because what's currently then going to increase the size,
and it does not know about how much.
So, except that it's for M,
it's very easy to build a histogram of how many value you want.
And this diagram will be on your local memory,
or in the main memory.
And again, you can walk with both sides.
Consider that the local memory is an observable pointer,
an observable matrix,
and the main memory is a,
non-observable pointer.
When we saw an angle the slide,
but being there,
I had some few questions,
because I was not able to list all the stats.
And if I create a number of contours with my new extension,
there is no way for me to list them.
I cannot know.
So, I must, which is the name of the contours.
So, I must, which is something to find my contours again.
So, maybe there is some improvement to do in a API
to be able to list that from extension.
So, you can check what you have already added to the main memory.
It will be very interesting to get a better control of when you flash the stats.
Because at the moment, it's a little bit fuzzy.
I mean, this is done by transaction, by time out of the things.
But, few functions have been added to be able to let you decide
more precisely when not to do it,
or bypass the pending list and have your own pending list
that you manage on your own,
but still a little bit are.
And I believe it will be very interesting that you can quickly
integrate extension statistics,
and make sure that extension developer can decide when the stats
should be flashed, merge, and so on.
And not let for the studio decide for that.
Because there will be a fun,
I think that if you have extension statistics,
it may be more of an application point of view
and it's not the same expectation from the other stats.
Okay, so, if I'm not too late,
we have some time for questions, maybe.
Maybe not.
Probably just one question.
Very, very intense talk.
Very technical.
Yes.
I think we'll judge them.
Yeah, of course.
We have to do it.
Any question?