Postgres FM - pg_stat_log

Episode Date: July 17, 2026

Nik and Michael are joined by Fabrízio Mello to discuss his new extension pg_stat_log.Here are some links to things they mentioned: Fabrízio Mello https://postgres.fm/people/fabrizio-de-royes-melloTimbira https://www.timbira.com.brPlanetScale https://planetscale.compg_stat_log https://github.com/fabriziomello/pg_stat_logCustom Cumulative Statistics (docs) https://www.postgresql.org/docs/current/xfunc-c.html#XFUNC-ADDIN-CUSTOM-CUMULATIVE-STATISTICSCustom Cumulative Statistics (wiki page) https://wiki.postgresql.org/wiki/CustomCumulativeStatslogerrors https://github.com/munakoiso/logerrorspgFouine https://www.postgresql.org/ftp/projects/pgFoundry/pgfouine/pgFouinepgBadger https://github.com/darold/pgbadgerpg_stat_checkpointer https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-CHECKPOINTER-VIEWpg_wait_sampling https://github.com/postgrespro/pg_wait_samplingRFC: pg_stat_logmsg (patch proposal by Joe Conway) https://www.postgresql.org/message-id/flat/89742024-d51a-c66b-90b9-67f837072cd2%40joeconway.com~~~What did you like or not like? What should we discuss next time? Let us know via a YouTube comment, on social media, or by commenting on our Google doc!~~~Postgres FM is produced by:Michael Christofides, founder of pgMustardNikolay Samokhvalov, founder of Postgres.aiWith credit to:Jessie Draws for the elephant artwork

Hello and welcome to Postgres FM. We share about all things Postgres growth. I am Michael, founder of PG-Mustard. I'm joined as always by Nick, founder of Postgres AI. Hey, Nick. Cool, Michael. And we have a special guest, Fabrizio Mello, who is the owner of Timberra, software engineer at Planet Scale, and creator of PG-Statlog,

which is a new extension that we're going to be talking about today. Welcome, Fabrizio. Thank you, Michael. We're really glad you could join us. So, PG-Statlog, do you want to give us a little bit of what it is, and why you started work on it? TG's tax log is, say, it's the Postal's extension, that solves a, at least try to solve a very tricky problem

on Postal's observability, that is, collecting information about your logs in several different ways, for example. So, currently you need to take your logs for an error, for example, your application is erring out for some reason and you need to detect what the error is happening after some deploy or something. You need to go search the logs, grab the logs and depending on where your post is running, it can be even tricky, right?

You have managed services, alternates, and all of different environments running post-list. So you can have a bunch of different tools to go to the logs and look for some. And PG-Stats log is essentially a view, it's a PG-Stat view inside Post-Clice that you collect counters, collect information about what is happening in your log. It is grouped by backend types, user, OID, database ID, SQL, error code, and every level. And you can configure PG-Stat log to collect different error levels, depending of how much information you want to Prentice those content. So essentially a brief introduction is this.

So make your life easy. Instead of you go to jump into weird tools to access log, you have all the information you need. The list is the basic information inside your post-clist. Then you can attach some manipulative tool and collect this information. And for example, see you over the time you're rating based on a specific application, for example. if you are

qualified for a mutual for a given user. So I agree with you this is a big gap in post-gust observability that we cannot understand error rates beyond a couple of things

there is a rollback counter like transaction, exact commit, exact rollback to counter in the database but what if it's some other error

happened, right? And also what kind of error? Is it just like uniqueness violation or it's corruption? like codes, there are three calls for like most painful codes, XX00, XX001, XX002. You mentioned error codes, there is a registry of error codes, but it's not possible to monitor them other than like just going to logs, but logs, I agree with you, it's hard to reach them often,

but also they contain sometimes personal data. This PII, for example, our stack for PostgreSQL, companies, come to us to analyze health of database. And we don't deal with logs directly, never. Because we don't want to tell them we deal with PII. Because everything we deal with is just metadata, some counters. And we want error rates like that, right? Grouped by, as you mentioned, by multiple things.

For me, most interesting is error codes. I want to know exactly, like, in past months, did we have any XX codes in this database or no? It's not possible to answer. It's insane. It's saying that it's not possible to answer, right? There's another thing which is not possible to answer. It's queries per second. Not possible to answer.

You can extract it from PISA databases, but it's maybe not the whole iceberg, right? Yeah, but it's a different story. I'm also thinking why nobody is attacking this meeting piece. But that's great. So you built this extension, and first question, you mentioned all these things to group by, Why there is no query ID there?

I think just because I didn't add it yet. Maybe for the next year we can introduce a query idea. We are generally in the query and providing the query idea. We can collect and store as a new T or this. Because I want to know which, for example, which queries had these errors. That makes sense, makes sense. Maybe it's expensive in terms. expensive in terms of overhead. We can discuss overhead slightly later, maybe, because it's a big topic.

But another question I had, why did you call it PG-Stat log, not PG-Stat errors or something? Because we can collect normal logged message as well. So I created a configuration, meet error level, that you can define what is the minimal error level you can, you want to collect. Not only there are also warnings and notices. Yeah, everything. You can collect everything. The default is a word, the mean our love is error,

but you can define any error land. Even the bug. I think the full is warning. Oh, the full is warning, sorry. Which is the same as you had a really good caveat section in the ReadMe. You mentioned about log me messages as well, which also defaults to warning. So by default, both match, which is nice. But if you want more than warnings, you also need to change that because otherwise they don't end up in the logs in the first place.

And you're using that hook. I think it's really cool for all the reasons Nick mentioned, but also potentially for more. I feel like there's probably quite a few things that are warnings in the logs that probably a lot of maybe managed service users or maybe users in general. just don't ever notice because they don't think to look in the logs for warnings. So I think exposing those via some monitoring tools or other tools could be really useful as well. Just show you you do have warnings going on in your logs, by the way. Let's name the core of the problem, the root of the problem.

There are like all this are reason of know methodologies like views, right, Brandon Gregg, views and four golden signals. we cannot apply them to post this right now without digging the logs all the time. And this is insane that you cannot apply basic methodologies. Because all of them include question, do we have a spike of errors, right?

We cannot answer. Let's go grab logs and answer. It's insane situation. Which means that demand in this tool is huge. Everyone needs it. Yeah, you can get rid of some complex stack like logs dash.

Yeah, exactly. Kibana. All these stuff, Kibana and just have your simple view and A-Skruz exporter or something collecting time to time information from this view and send out to a firmware tool. Gras use something. Exactly. Like you can analyze it inside the database. I saw weird extension.

By using our tool, your PG-E-SH. Yeah. Yeah, like that, like just self-collecting samples and understand like buckets and so on, like it's possible. But also because of lacking this observability piece, I saw long ago like RDS had it as well. Extensions like foreign data wrappers over logs just to bring this visibility about errors and something to SQL context, which is like absolutely crazy things. So yeah, that's great and it's great to have it. But everywhere we discussed it so far, and this podcast won't be an exclusion,

I say, this must be, I'm not asking, I'm just saying, this must be in core. Yeah, what I was about to ask you, why do you want, do you think this should be in court? It truly in core, not as an extation, because my plan right now is specped this as a contributon and soon as to upstream. I didn't read yet just for fine real. Like PG stat statements. Right. Yeah, like PG stats state.

Like PG stats stated. That's great. I think this is an absolute minimum that needs to be done. But I also think that just a statement should be in core. To avoid this friction of create extension. And this should be in core just because, again, any serious methodology includes error analysis. and it's not available without digging logs.

And digging logs is not always possible because it has a PII and not all people have access to it. Not all external people or internal people sometimes they don't have access because there is PII, like emails or something, right? We just don't need to know basic thing, like error rates. Without building this stack with Kibon or something, I never saw it working really well. So many companies built this.

But the only thing, I saw was working quite well was Splunk, which costs millions of dollars. Yes, Splank costs millions of dollars and requires the whole team to manage additionally. It's a great piece of software, super expensive. I don't see any startup that could afford it, actually, in terms of money and people allocated to manage it. So it should be simple. Like error analysis must be simple. That's why it must be in core, available to everyone.

And you know that. talking about simplicity. This extension was something that I wanted to work for a long time. And the main reason I didn't start it many years ago was because, oh, I need to build an entire PG-statement like extension. With serializing the information to somewhere in the days, deserialized this information and all of those stuff. It's a lot of work, right?

And then I always have something else to do. And I never read. Then the new picture Postgres released on PG-18 custom cumulative statistics. That is great because open the doors for the existential authors to create their own statistics like F. And then the statistics collected of Postgres, you do the job to collect your statistics. So it abstracted a lot of complexity of dealing with a lot of memories of serializing the serializing stuff. On Postgres and on the extension side, we need to deal only with the business logic of the thing, what you want to collect, right? So this is one of the reason that I started.

The second reason is, okay, I need to try more AI tools because I'm old guy. trying new AI stuff and then I tried it. And the third reason is because Nick liked it very much and pushed me a bit. We need to do this. We need to be to have this in core. So let's do this. And then I bootstrap the first version and then Nick helped me using AI tools, reviewing, testing and all of the core case. So now we have a good state of code that is.

good enough to tend to upstream like an on TV modern like a R-Sync. Those are one of the reasons that I decided to do this right now. It means that this existential don't work, for example, with PG-17, 16, only on PG-18 and next virtuals. Nice. I saw you already added 19 support as well. Was that much additional work, or was that relatively straightforward in the

end. I think it was only one macro, only one small piece of course, it's just one commit to make it to work. The most part of the next issue is the same. Because some internal data strictors was renaming all moving around and then I just use it a macro tool to make it compatible either on 80 and 19. Even on main pulses branches, compatible right now. Nice. Perfect. On the 20 development cycle.

That's good. Let's talk about a little bit about overhead and observer effect. What's the price of having all those counters? I did some very basic benchmarks. The overhead I saw, setting the mean level to log to log everything and running some DG bench synthetic workload I knocks around 2 to 3% of over there. What was QPS and how many log messages per second?

I don't I think I have this information issue. Yeah I'm very curious. Maybe I want to dig myself. I just need fine time with it, which is hard later. Yeah. I would like to scrutinize it. Just to be clear, though, the default here is warning, and we're all saying that it would be useful at warning or even error.

It would still be extremely useful. So presumably at those levels, it's going to be near zero overhead. Yes, exactly. Yeah, I tested on the worst case scenario. Right. Yeah. One of the worst case scenario, logging everything. and then collecting everything.

And then now I discovered something that I'm working on because we need to configure the capacity of how many lines we collect, how many entries we're collecting in this PG-Stat log, like PG-Stat Statement. And PG-Starsetments is 5,000 by default, PG-Satement.coms. Yeah, exactly. And then a new district entry came

I'm not doing all the one now with it when. And this makes expensive. I have one entry that should be discarded, should be dropped and not collected because my list is full. My list of entries that I'm collecting right now is full. So this, I think Nick advised me to create this drop-ed information on the ID Start Log info to see how many messages were not collected. And when we reach to this point, then the performance is even worse.

The overhead is like 20% or 30%. So I mean, here working the main algorithm too don't be so expensive. Right. We talk about other heads here on the edge case when it's basically it's stress load, when we have a lot of log messages happening. and it's worth noticing that these messages go to logs as well, right? If we have so many log messages, we have observer effects there anyway. Yes, you have probably anyway because your log is.

All queries, this is simple. Let's set a log statement all, and let's go. This is how you can put your server down if it's loaded. So it means that overhead you introduce, it's like sister or brother, of we already have in logs. Yeah. We're just slightly amplifying it, right? Amplifying not badly because

Ovid hat from writing to disk is high. If you write 1,000 lines per second through logging collector, you will notice this. And I know it. You will notice it. If you increment some counter thousand times per second, you also probably will notice it, but less. Right?

So we should log less. This should be a rule, right? And exploring overhead on edge case makes sense just to understand like how much is... Maybe we should explore with flame graphs as well in normal conditions, like how much of it goes into these functions. Also, contention risks. Obviously, you have some light wet lock introduced, right?

Yes, I have some lightweight lock introduced. But the good news is that this is processed by a stats collector because it's done on the stats collector side. But anyway, it's teasing the hot path of the emit log hook. So it creates content. But mostly CPU condition. Memory condition is not too much, but it's more CPU contention. It's not this condition because we are not writing anything on this, on that station.

It's done on the stats collector when you shut down the server and it started. the server because this is done by another subsystem, not in the extension itself. We have a new abstraction that custom cumulatives that is created that is great for extension developers. Yeah, that's important. So it means like a safe restart, like not a crash, the stats will persist. Yeah. Yeah.

But on crash it would be lost, which makes sense. Yes, yes. It's the behaves like PG stats too. I think also granularity matters, right, because if you have some only some limited number of aggregated entries, right? So we aggregate by error code, by database who said, user and severity level, right? But if we, for example, have a very volatile situation, I don't know, like maybe a lot of users we have, or maybe a lot of databases. So we have a lot of entries, we probably don't want them, right?

For example, my first quote is maybe I don't want warnings, right, because it's too much, too much information. I know I will be paying for this overhead. Maybe I want only errors. But at the same time, I know some warnings I definitely would like to see. For example, warning about gilipc, collation, mismatch, like, suggesting that maybe we have some corruption, silent corruption, so on. These warnings I definitely would love to catch. Also, there are some errors I definitely would like to ignore. For example, Uniquist violation, counter is good.

But what if, like, we start that database and it says this very famous error message, Fatal database is starting. It's not an error, actually. It's just like a quintuble bit. But it sees like a error and we can have spike of errors, which means that imagine we have all of that. To properly tune alerts, I probably should make some dance around, filtering, what I want, what I don't want, right?

And maybe it should be done not later, but sooner. Maybe I should just cut some messages. And this could be some like filtering. Yeah, some filtering configuration. Yeah. Make a lot of... I just don't need these warnings, shut them down. Anything like this.

Maybe it would make life easier because usually what I don't want is something frequent noise for me. And in this case, if we can discard it, it makes the tool more lightweight, right? So overhead lower. Just brainstorming a little bit. Yeah, you can also create some filtering or a specific user you want only to track information about a specific user for them.

Why not? Right. But this is only later because you track all users. I can say I want to only use you. There is no such filtering. Anyway, so you mentioned this cumulative statistics mechanism appeared in Post-Gbius 18. And this is great.

Postgwis once again became even more extendable, extensible, right? Which is good. I noticed you registered code, I don't know, 28, right? The kind of statistics. Yeah, the kind. Right now the process is very interesting. You go to Wikipedia and put it there, right?

I know. 27 was Pigeist of Plans from Lucas, people, right? I think now you 28, also after you who came. Spock, PGH, right? I think, yeah, 29 is Spok and then number 30 is PGs start login. So we have only four lines right now, because this is super fresh. And you were number two, actually, among this form.

That's great. I have two questions, actually. I know there were some attempts to create such like this thing, like cumulative counters for errors. One of them was called extension or was called log errors, right? And I'm just curious, what are benefits from switching? Because we use log errors in a few places. I understand the internal benefit.

You use like an official way right now. And I suspect data in your extension will survive restarts unlike log errors. This is I see easily because they needed to implement their own piece of shared memory and all machinery around it, right? Maybe it will survive as well if they implemented it. What else? Obviously, you will take care of warnings and your granularity is better. Maybe you will introduce queradis, which will be nice but dangerous and expensive, right?

Like, what else? What's the benefit? Only aware about this extension that aren't mentioning, I don't remember. Yeah, log errors, one word without underscore. Ah, log errors. Okay, I found. So it's old I can answer for you

the main benefit will be if it goes to core or at least as Contrip module this will become packaging much easier yes obviously yeah yeah and since you chose this new

approach but what are the chances obviously Postgreene 19 is already past beta 1 beta 2 is coming so cannot be included in Postgreene 19 Do you have plans for Postgres 20?

Yeah, so Postgres 20. For sure, next. Commit first. I will be published for next. Yes. That's great. I'm definitely willing to support with any more testing and so on. I just want this to be there because so many clusters I observe which needed. And I just, honestly, like, when we needed to analyze performance using

originally PG-FU-In and then PG-Batch, PG-Fee, you remember in PHP? Yeah, I remember you, they pull up. Yeah, P-G-Bitchie. And I remember guys who said, we are going to switch on logging or everything for five minutes. It will be hard for everybody, but we need it because we need to see the whole thing.

And now we have PG-Stat statements, PG-WAT sampling, P-G-Sat-Samp thing. and also another approach is like active session key story approach gray but errors still the problem right and I just don't want to deal with logs like that I want them to be a mechanism when we already understood what's happening at high level and we need examples then I want to go to logs but the scale of the problem like to triage the problem I don't need locks yeah so absolutely

That's a good question. I think do you have a math tools now? Don't need PIGBed? Excellent. I haven't touched it maybe five years. I don't need that. Me neither. More than five years.

But in bigger companies, I deal with, we usually have some already flow to process logs, either from RDS, CloudWatch, pull them, put them somewhere. So they have it, but they usually have it, not because of post gas, but for everything, right? So some log collector and analysis, elastic kibana, all this, right? But I touch it less and less.

And I don't need it too often. So, yeah, once this is there, at least as a contrib module, life will become much easier when we have incidents, right, and we need to quickly understand what's happening. Michael has now. I actually think this is more interesting, not necessarily from an incident point of view

than from an ongoing minor issues in the background type, things that would go unnoticed otherwise. I think incidents, normally somebody's on the Zoom who can access to logs and can check, it does have access to those things. But I'm thinking the warnings that are building up over time that people aren't noticing or the errors that they're affecting some users

but not enough to complain about. Those kinds of things. What are our 10, what are this application's top 10 errors this month or this year or whatever? I think that's super interesting, even outside of incidents. Maybe it helps with incidents too, but I like that on the bring. Inside incidents, usually, it's messy. And a logs, the incident produces a lot of logs. It's really hard to deal with them.

You need tooling, you need expertise. Of course, AI helps to process in large amounts. But when you have a lot of, basically, bias to process to fetch a few months. numbers. It's easy to make mistakes and the LLM make mistakes when you feed too much information to it. If you have very structured counters, it's great. Also, log can rotate, you can analyze the wrong log file in the middle of rotation or something and so on. And storing those counters in some time series, like snapshots over time. It's so much easier, so much more missile. And in general, Postgis moves in this direction. For example, we have to be a lot of times. We have to be a lot of

had checkpoints and auto vacuum, most data only in logs. Now it's slowly moving PG-Stat system. For example, finally, PG-Stat-BG-Writer, which always collected information not about PG-G-Riter, but check-pointer and back-ins as well. Now it's already reorganized. Also, there is P-G-Stat checkpointer, there is P-G-Sat-B-G-Riter. It's more obvious.

And it's easier for LLM, actually, to analyze what's happening, because naming matters a lot right now. That's why I asked Pag0. Is it like, I wish if there was specifically PGSTAT errors, because we have errors what kind of, right? But I understand the reasoning, warnings and everything. I understand that. So counter-efficient, the process of analysis, efficient.

That's important. And complete. That's also important. And fast. Yeah, you can immediately understand where, when exactly spike happened without gripping. I'm talking again about overhead. I think the overhead introduced by this extension is way less than PIGA Statenberg, for example.

That's interesting statement. We should maybe put it up somehow with benchmarks, think about it. Yeah, that's interesting. Why do I think so, by the way? Because of what we do in that station is a very simple. It's a hash. PIGSASS also. Yeah, but PIGSAT even need to normalize the query

and do a lot of other stuff. Oh, yes. Yeah, exactly. And it takes time, few cycles. I proposed the introduction of Qaeda ID, right? You don't need to normalize, right? No, I don't need to normalize, right?

Yeah, because in logs we also compute QREDI mechanism, right? On the query ID front, I think one of the downsizes it would balloon the number of entries you would need. Like, you've currently got the max entries to 1,024, which feels not that high, but actually, if you think about how many people actually run multiple databases on the same server and actually have, like, thousands of users, it's probably pretty low.

Probably most people have a few users that are doing a lot of volume, and each of those things you mentioned is probably fairly low card analysis, so that by the time they all multiply, it's probably still below 1,000, which is great. But if you add query ID into that as well, that's a much bigger number. Yes. One thinking about introducing this, the query ID, maybe it can be optional, a boolean configuration that you can turn off.

And then you always have the query ID and if you don't collect query, it will be zero, for example. So what's the downside of increase? If I increase Macs entries by a lot, I guess that's just more shared memory and slightly more delay on writing it out on restart. Are there any other downsides? It is a sh map in memory. That it depends on how many entries in your CPU. And yes, but right into the disk, I don't think, unless you have. It's not a lot of bytes.

Yeah. No, because I'm not writing any text, only integers, is written. True. It is kind of. Regarding query idea, PG-Waid sampling also has this as optional. This parameter you can enable profiling. A query, so similar approach.

And I think it's even off by default. I think so, maybe I'm wrong. And we usually enable it because the information from PG-Wate sampling is super useful and we wanted to be RQua-Ready. So, yeah. Cool. Maybe add QREDI but also bump the default way up. If there's very little overhead to having 10,000 or more,

I don't see why that should be limited. What do you think? The things for asking this, this was an arbitrary number. That got from my... Probably I should include. this and maybe match with, for example, PG-Stat statement, because it don't require too much memory. Be honest, yeah.

Nice. I noticed you labelled it version 0.1. What else do you need in terms of getting it to a version you could commit to Postgres or 1.0 or whatever, however you want to define, like, production ready? The thing that it's blocking its submit is this issue that I find. in the worst case when we have all the entries fill it and then new entries entering the dropping message.

I will not collect information because I don't have enough capacity to collect. And this is another worst key in the corner case. And then I found that overhead is it's not great. It increased by 27, 30% of overread. And actually it was not

it's I think just this for now, a starting point, maybe query ideas something to discuss with the community. I don't know. There are ongoing work in the past. There was ongoing work in the past and work in progress. Yeah, no, a major patch to introduce PG stats, log error or something. It was proposed by Joe, Joseph Conway. And they collected this old discussion.

They collected their file name, the source code file name, the line number, where there was coming from, that I don't think for real use kings is a good idea. I mean, for SREs, DBREs, for people that actually use it, I don't know if it's useful to know where is the C-5 that the scale came. I don't know. Maybe I'm wrong, but I thought that was not useful. And then I started by the base stuff to really observe the log, a backhand type.

What's the database ID? What is the ever-level and the SQL ever-code? Because I think this is the basic. information. Now that Nicky mission, right. Yeah, the can be an option. Files. File is always the same. It only can change after rotation, right? Not the log file, the source code file. Sorry. They see file, something dot C inside the posters, and the line the number, because we have

this information. So I see. So we have some error code, for example, my favorite X001. for example, right? I think it's some corruption or something, right? Or zero, zero two. And we know that in PostGis source code, it happens in, it can occur in five places, for example. And we want to know exact location of among of those five, right? I think this can be useful.

It reminds me, like, when programming, you troubleshoot with printlining, right? And you have, like, problem happened, probably, or test, test, like, something. And then you think, oh, there are this. Well, you need to start distinguishing them, right? You say, okay, test one, test two, test three, and then which one of them fired, right?

I can see it may be useful, but again, what overhead? What's the price, right? And the price is we need to store variable-sized strings. The line number is not a problem, but the file name, the source code file name, it's a string with a variable size. then it can increase the memory. Or the tendon of how many entries you store. Right?

But, yeah, the source code fire names are not very big names. But I don't remember if you have multiple file names, equal file names with different directors. I think it might happen. It might happen. And so if we start only the file dot C, line number, 1,000, and then you have two files the same name. It can be compared somehow, I think, quite easily, so a few bytes only.

But is it really needed? Maybe no. But it's a nice feature, I can imagine, like to trace the exact location. What I'm concerned about, not about, like, additional bytes, but it will amplify like number of entries, significant. Yes.

If it's the common, if this error is popular and we have 100 locations, so now we have 100, like different errors, basically, right? Yeah. But it's like interesting. It's interesting anyway.

Yeah. We should have it in, this information should be present in logs. This is verbose, detailed information. Go to logs and troubleshoot. It's the level of fixed extension. We just won't count. to observe holistically everything.

Right. And then if you identify the spike, go to logs. Now the problem is we cannot identify spikes at all. So we're... Yeah. Yeah. So I agree with you. It's to view both stuff.

Yeah. Okay. It was some kind of brainstorming session a little bit. What I think would help is if somebody starts using it, maybe not in production right away, but in some benchmarking, like I'm going to start using it in some benchmarking. some benchmarking activities in the lab environment, right?

So first, like, low risk. If it crashes, I will let you know. But eventually, I think in production, it should be in production. Oh, it could be very useful. Nowadays, it's packaged for Demium and RPM on the PG, DG, people stories. So it's available there. I can provide some docking images, but a docketing is very sweet.

you can pick a poster, something, and just install a new package that PGDG is there. Cool, but also, Osgo's 20 development already started, so we already inside it. Let's call there. Yes, let's go on there. You don't skip from that. I wanted to be in core. This is great stuff. Yeah.

It should pick. Was there anything you wanted to mention that we haven't asked about? Maybe some of the caveats. that you wrote about or anything else? One thing that everybody can potentially ask is it requires best artists because I need to allocate sharing memory. So there's no way nowadays and post-kitch to do this without something. I think this is one of the reasons that Nick would love to have this truly inquired and we don't need to restarted both six.

But it depends often how it is implemented, right? Because there are some configurations that when we change it to hysteria in ways. Yeah, this is definitely why I think a Pitchisor's admin should be in core as well. We still have cases when it's not installed and it's not present in shared preload libraries, so we need a restart.

Exactly. Yeah. And this requires shed preload as well, doesn't it? Yeah. And there are only another caveat that we didn't. how could you use the parallel query, right? Because there are different backend types, parallel queries. There are a normal client in the queue that is the leader.

And then you'll be a parallel worker or something. So, don't count twice in the message maybe. Yeah. So I'm not filtering anything. I just collecting on the log because it's going to the log to the log, the information. the information. It passed through the Ennithlogue hook and then I capture the leader and also the parallel workers. So we feel

and I'm monitoring tool and taught them I have parallel workers. You should filter it out about double com something. It's one caveat. It's it is on the movement. Yeah, I thought it was really interesting. I thought that was a good one to call out and I thought the other one that was interesting for monitoring.

was the fact that database name or username could be null. And that's expected. Like some errors happen before there's a context of having a date. Like that's something I would have forgotten to do. So for example, I knew I wanted to monitor one database on Postgres. I would have filtered by that and only looked for errors. But I need that database name or null. And then I look at errors across both of those.

So that was a really good call out, I thought. Nice one. I didn't thought too much, but maybe another thing that's interesting to collect the aggregated application. Oh, it's Fondora Box. Yeah, I know. There is a great idea that, well, what about client address and IP address and so? It can't go far.

There's a great idea that all such extensions, like Pugster statements, PugSat K-Cash, PG-WAT sampling, and VFPGPTLSTAT. logs, they all must have an additional extensibility piece, so I could define my own dimensions. For example, if my query contains a comment which says, this query originated from this part of application, and anything, I just can tag my queries. If those tags could be extracted from comments and allow me to group by tag value inside Pugis statements or any such extension. This would be great.

This is a big lacking piece. And right now, the way to go is to avoid the cumulative statistics approach completely and just use, instead of counters, just use sampling. It's basically you can implement the same in active session history approach. You sample productivity, you have these comments, you extract outside of Postgres, right? And then you can finally answer, okay, I.O. Weight event, we mostly spend 90% of AIO registered in Weight Event, was in this piece of application, this part.

Because it was tagged. In the case of your extension, same thing, if something is erroring out, group by database, group by a user, even application level, it's great, but sometimes we need some custom segmentation. And now it's difficult right now. This is maybe future of all those extensions to have custom tagging mechanism. Maybe. These discussions, I know people and myself,

we discussed it over years. You actually, Fabrizzo, is a part of the background group where we discussed it, I think, a couple of times. So anyway. Great. Thank you for coming. I enjoy it. I wish all the best to this extension and all your work.

Thank you very much. Yeah, thank you. Thank you. I hope it will be. Absolutely. Good luck for version 20. Take care. Bye.