[00:00:00] Michael: Hello, and welcome to Postgres FM! My name's Michael, and Nikolay, as normal. Hey, Nikolay!

[00:00:06] Nikolay: This is first time you changed intro. Hi, Michael.

[00:00:10] Michael: Yeah, trying something new. I was sick for the last couple of days and now suddenly I'm And obviously I missed a week I was at a conference, so sorry I couldn't join you last week. I hear you got another co host. Some people liked it, some people didn't. So I'm grateful to the ones who wanted me back.

[00:00:28] Nikolay: Yes. First of all, glad to hear that you're recovering. And second, the most important that I didn't liked it. So, I mean, I liked it sometimes. I mean, ChargerPT, right? But, uh. It didn't, uh, obey. I said, uh, don't talk too much before I start recording, but it started to talk too much. Really, like, stealing agenda and so on, and moving us to wrong directions.

But it was interesting, small experiment. it's good that you can chat with it, on voice. I use it. while I'm driving sometimes to brainstorm some ideas, including Postgres ones, so it's interesting thing, like, you can ask some things and brainstorm, like, I have this problem, let's think how to do it.

And when you finish driving, like, sit on with your laptop, you already know. You have more ideas in your head, so I think it's interesting. But for podcasting, no. No.

[00:01:21] Michael: Or at least not yet. Thankfully. Cool, so this week I chose the topic and I've chosen query hints. or lack thereof might be a, a good little in brackets or subheading. how do you feel about that choice?

[00:01:35] Nikolay: Good choice?

Yeah, let's talk about it. Where to start?

[00:01:40] Michael: I think we should start with what do we mean by query hints? And I, I was going to suggest that I think there's, it's almost in the definition that there's a little bit of argument here. I think where they come about, well, why, why people ask for query hints in Postgres is that they have a query

[00:01:59] Nikolay: because they came from Oracle world.

[00:02:01] Michael: Yeah, basically, or, or other database management systems that allow you to give the query planner hints, or stronger than hints, of how to execute the query, which is kind of a little bit against how... SQL is designed, but through a lot of requests or through a lot of planners that make bad choices over time, or kind of emergency situations, they've kind of become the systems that have implemented it as a feature, people find it very useful at certain times, and therefore it becomes a feature request for Postgres as well.

Is that a fair summary?

[00:02:39] Nikolay: Yes, but they promised us, SQL, and if you check the SQL standard, it doesn't have the concept of indexes. Indexes, not hints. Indexes. So, fully declarative language, right? You just ask something, you get something. That's it. The speed, who knows what happens. But we have something, like, hints in the pure Oracle meaning, it's like some comment, which is not a comment, but direct command to the executor, to the planner, which plan to choose.

Like, for example, I want this index scan. Use it here. Don't try other index scans or sequential scans or anything else, like right? And here, for example, use nest loop, don't use merge join or hash join. So, this is hinting in a narrow sense, but if we consider this in a wider sense, like any suggestion to the planner, how to behave and what to use, what to not, we already have a lot of things.

For example, a set of enable... underscore something settings, like enable sex scan, enable index scan, enable bitmap scan, and things like that. Enable, enable memoize in Postgres 14 or 13, which is probably should be by default off. I, I think I, I saw case when, well. I saw the case when it made things slightly worse.

Not slightly, I mean, leading to some timeouts and for safety I would, moving to Postgres 14, I would probably keep it off for some time and then

[00:04:25] Michael: I've seen the opposite in cases. Yeah.

[00:04:27] Nikolay: Okay, yes, yes, yes. Yes, but it's, you know, when you move to a new version, you probably want to be conservative and to minimize the change, changing parts.

The shock of CT behavior change in Postgres 12 still in memories, right? But back to the topic, in a wider sense, we have a bunch of these commands and we also have another hinting tool, multi column statistics, right? You need to manually create some parts of statistics. It means that you suggest some new stuff to the planner.

Of course, indexes also can be, if we take hinting in very wide form, indexes also can be considered as something like, well, it's a little too wide, right? It's already

[00:05:20] Michael: I think that's more kind of like statistic, like there's statistics around indexes that I would consider part of this,

[00:05:26] Nikolay: If it's an index on expression, you must recalculate statistics, because if you create an index on a column, or a multi column index, or a partial index, it will use existing statistics,

[00:05:37] Michael: yeah,

[00:05:37] Nikolay: because we know everything about, I mean, Postgres knows everything about columns, but if you create an index on expression, in this case, Postgres does know statistics for values of expression for each row, so we need to say, analyze table, And, uh, it will extend the knowledge of statistics with these, uh, values this expression provides.

But there is also multi column statistics, oh, and there is also default statistics target, or ability to adjust the number of buckets, either globally with default statistics target, or individually for particular tables, columns, right? In

[00:06:19] Michael: it allows you to, allows you to effectively control the sampling. So you can, you sample more of

[00:06:26] Nikolay: How many buckets, right? By default, it's 100. Some people say, let's go down to 10. It's very, very strange, I think. Usually, people tend to think they need more and increase it. And once you increase it, analyze time takes longer, and it's very hard to go back. Because you have fears that some queries will behave much worse.

[00:06:52] Michael: yeah, I've seen a lot of people on OLTP systems change it for a certain number of, highly skewed columns, but increasing it globally. Yeah. I think people underestimate the impact of increasing the time of an analyze, because as we've talked about in previous episodes, that's an important step for some types of like recovery or, or, migration, you need to do an analyze before your system can really be considered.

[00:07:18] Nikolay: And I agree, analyzing stages, in my experience, quite often doesn't work well, like, I mean, it's better to admit its maintenance window, do as quickly as possible to perform full analyze if you have default statistics target like thousand or so. 2000. It takes some time and analyzing the stages leads to having poor plans and overloaded, like, CPU usage is high, like, it's like, it's not a good idea in some, in my experience.

I understand the reasons behind this feature of VacuumDB to support after upgrade, like, let's open gates faster. But it's actually, okay, it's another story. Let me mention Also, the trick people use, and I also used it in the past until Peter Gagan mentioned on Twitter that it's not safe, so now I don't recommend it.

The trick is, like, for example, if we, want to drop some index, considering it as redundant or unused, we, since it's huge... Index, we probably want to soft drop it first.

Mark,

[00:08:32] Michael: in MySQL for that, right? But we don't have it in Postgres.

[00:08:35] Nikolay: right. It would be good to suggest globally again, like, guys, all queries don't use this index. And if you don't see any degradation, then you actually drop it.

But, and you can do it with update, pgIndex, setIndex, pgIndex, pgIndex, pgIndex, pgIndex, pgIndex, pgIndex. Index in, in is valid flag two. False. Uh, Postgres will keep maintaining this index, uh, in actual state, but the planner will think it's not anymore valid, so it won't use it. But, uh, Peter, Peter Gagan. Uh, it's uh, not safe operation and uh, so we don't have this.

[00:09:17] Michael: Oh, is it?

[00:09:18] Nikolay: I don't remember details. Something like some, in some edge cases, uh, it might lead to some kind of corrupted index or something. Like, I don't remember details. We can provide the link. so I just remember it's not safe.

[00:09:31] Michael: yeah, and we can trust Peter.

[00:09:33] Nikolay: Yeah, yeah, because he knows

everything about bit, bit, bit, rewrite, yeah. So, but this feature would be really nice to have.

This is exactly when I would like to have hint, but... Not, not for queries. I want, I would like to have some, global way because this is, like, I don't want to change queries when I do this. It's impossible. I have, like, workload is complex, right? I don't want to rewrite application code, but some setting, like, Disabled indexes.

There is also a very old extension from Teodor Sigaev called PlanTuner, which supported exactly this functionality. Like, disable some indexes temporarily for the planner. And this is a great idea. I'm not sure, by the way, if pgPlanHint Plants, plant hints, supports it. I think it doesn't support it, but this is a very, very good use case.

People very often ask me about this and I explain, no, don't, like, I explain there is some hack, but now I don't recommend using it.

[00:10:40] Michael: Interesting. So, I feel like we've actually got, dove pretty deep and pretty quickly into the root of the problem. I was really enjoying doing some research for this episode because... I had slightly misunderstood people's summaries, or maybe, maybe their summaries of the threads in Hackers were slightly misleading, because I was under the impression that there were people in the core team that were seriously against query hints in any form, and actually reading at least, I read one of the threads, which is quite long, from top to bottom, and really it was very reasonable, counter arguments against inline comments in You know, per statement level, the Oracle style query hints.

It wasn't a full on rejection of hints at all. It was just the implementation that Oracle had that was particularly not of interest. And that, yeah, that was not how I'd heard it summarized. So that was super interesting to me. And this, it very quickly turned into a discussion of normally the root cause of the planner choosing a plan that is Suboptimal or terrible in some cases, which is, which tends to be the time these discussions come up, is it's make, it's got some bad data.

Maybe it's got some, uh, maybe it doesn't know the correlation between two columns, or maybe it's stats are out of date, or maybe it doesn't know how many rows are going to be returned by a function. There's so many places

[00:12:10] Nikolay: Maybe a plant flip happened suddenly.

[00:12:13] Michael: Yeah, exactly. So maybe, maybe your distribution changed. Maybe you've got more data

[00:12:17] Nikolay: there's a bug in Postgres code,

[00:12:19] Michael: yeah, exactly, exactly. It could easily be.

[00:12:22] Nikolay: it can be both sides, some like, uh, something wrong on, like, human shoulders or something wrong on Postgres shoulders. So in general, I think... I understand the reasons, like, first of all, I observed this discussion all 18 or 19 years of my Postgres experience.

I, I, I saw it, first I saw hints in 2000, I think, or so, or dealing, 2001 probably, dealing with Oracle 8i, and I saw a lot of curious people just use the hints all the time, like all the time trying to have predictable By the way, there are different goals here, right? So, first goal is I want to fix some particular query.

Another goal is I want predictable plans. Like, for example, I, I have already large tables. I know they will grow, but distribution, like, won't change too much already, and I just want to freeze. Planner decisions. Because plan flips happen and it's very painful. they don't, they're not often, but they

happen.

[00:13:31] Michael: that's, a really good point that there are two, these two things. But I was thinking the majority of times I've seen it raised is in the context of something happened, my query plan that was working fine before is now terrible, how do I flip it back or get it to choose the, in inverted commas, correct plan.

But the other case, and that, that gets heavy pushback on what's the root cause. Can we fix the root cause, et cetera, et cetera. But the other case is super interesting. And I think the more I learn about performance, the more I think it's important, like more important than people give credit for it is we don't always want optimum performance.

We, we care much more about predict. Yeah. And that's even what I was saying was predictable. It's hands out. but yeah, a hundred percent. if there is a trade off between, on average, doing a query slightly slower, but it is always within a much smaller, uh, variance, most people would pick that one.

distribution over one that is on average faster, but every now and again has these flips to a really slow experience. So it's, yeah, really good point. And there are some, again, commercial databases that have the, the idea of this kind of plan

[00:14:45] Nikolay: most popular commercial databases have the ability to control, to reach this predictability because enterprise needs it. That's why Aurora already implemented this, right, you know, query plan, plan management system. Unfortunately, despite the fact that AWS engineers contributed, like, a lot in the last one or two years.

I saw some statistics, probably you also saw it, right? this good extension is not our system. I don't know if it's just extension or it needs additional, like, uh, like tooling, uh, outside of Postgres. I think it's just an extension. Unfortunately, it's not open.

[00:15:23] Michael: Not

[00:15:23] Nikolay: It's very, very enterprise feature, right?

But I think, uh, many... People need it. I think it's very good to, it would be very good to have it. In Postgres we have only, like in open source ecosystem, we only have pg, pg hint plants.

[00:15:40] Michael: PgHintPlan is the former, it's the first thing, right? That's the Oracle style, query level hints, that let you choose things like, um, I've written it down so it'd

[00:15:50] Nikolay: Yeah, just, I say, yeah, use index scan here, always. Using this index, always. Talksciencesdata.

[00:15:58] Michael: Yeah. So scan methods are one, but also you can, uh, hint, join methods, join orderings, really important, row number corrections, which could normally when the costs are off, it's normally row number related and even, uh, in lining some of the GUC settings as well. So they give you access at that level, but there's another, I think there is another extension for the query plan management stuff.

A member of presentation on it by, I've forgotten their names, but somebody from the French speaking Postgres world and somebody from the Japanese speaking Postgres world, they did a joint presentation on it. Or at least, I think it might even have been two extensions that work well together. I'll find the presentation and I'll link it up.

But yeah, that, I feel like it's a slightly different discussion though. I can't remember the name. Anyway, I'll hint, I'll link that up, I'll hint that up in the notes. Uh, anyway, should we talk about some of the... Kind of alternatives we have within Postgres, because we have, we have pgHintPlan, it's available on some of the cloud providers, but not all, it might be that you don't want to use it.

but there's, there are alternatives that we have, right? How do we solve these row estimation problems without,

[00:17:09] Nikolay: Well, it's, it's, in general, it's very hard to solve. So, so it's, if you think about it, it's quite scary. if you, the more, the more you think about Uh, risks of plan flips, the more it seems to be scary because, uh, you don't have, uh, official ways to control predictable, behavior of the planner, except besides, uh.

Tune and monitor autovacuum behavior, so analyze part of autovacuum activities is always like up to date. that's it basically. You just need to make sure statistics is fresh.

[00:17:45] Michael: I think, I think we have a bit more, we have quite a few more tools. We've mentioned some of the tools already, right? So yeah, out of date stats is a really good one. So making sure they're. Uh, up to date on a, yeah, not a big enough sample is like an interesting one as well. We talked about extended, uh, not, uh, we talked about increasing the, uh, statistics

[00:18:03] Nikolay: number of buckets. Default statistics.

[00:18:05] Michael: Yep. Or the sampling.

[00:18:06] Nikolay: this won't help you with plan flip. Plan flip can happen tomorrow because of various reasons. And because of, for example, like, I don't know, like, if, in some very narrow situations, if you have, like, default statistics target default, like, 100, and then suddenly on, like, on the edge of your table, data is kind of different and you deal only with this data and it happened to be only in one bucket. In some case, probably, the plan flip will happen. But also, the most, worrisome problem is related to some bugs and, imperfect behavior of the planner. For example, I had cases when inspection of merge join path.

led to huge planning time and it was like, it was, we were able to fix it with enable merge join to off.

[00:18:57] Michael: Exactly.

[00:18:58] Nikolay: Right. But, but it happened like suddenly also, like everything was normal, but suddenly some query degraded.

[00:19:07] Michael: Yes.

[00:19:08] Nikolay: yeah, so.

[00:19:09] Michael: I would say that the typical arguments for query hints, kind of inlined comments, also have those challenges. They don't stop plan flips either. They're still based on costs, cost models. so normally people don't argue for the hint. Like, let's say... It forces you to use an index, but you've, you've, uh, dropped that index and created a different one, and it no longer has that index.

Do you want the planner to still try and use an index, or do you want it to error? Most people don't want the query to start erroring. They'd rather it was more like a cost, uh, model change than a, than a forced hint. So normally hints wouldn't fix those problems either. So. In general, it's only the other thing we talked about, the, the kind of query plan, uh, management feature that would, which is, it's not really hints anymore, is it? That's like a, almost like a

[00:20:04] Nikolay: Yeah, well, yeah, right. So, so right. So we have different goals here. Let's repeat them once again, probably slightly extend. One goal is to fix particular query because you cannot reach good behavior from the planner. You know, like, it should, for example, use nest loop, but it somehow uses merge join and, and the first thing you need to do is to check that statistics is up to date from analyze.

Next, probably, like, consider raising this default statistics target or this number, like, tune it at column level. Maybe no, like,

[00:20:41] Michael: Or, or what, what I would do is look at the query plan and look at where is the miss, where is the mis estimate. Getting, uh, where is it worst? Is it in the, is it at a single table level on the kind of, on a, a where condition, for example, for two columns in the same table? If so, we've got the extended statistics tool

[00:21:01] Nikolay: Right. Right. Yes, exactly.

[00:21:04] Michael: If it could be, and I know you dismissed this, but if you raise the, amount of sampling on a specific column, that can help avoid flips, for example, if you're dealing with a value that is currently in the most common values, but slips out of it, because you're not keeping enough of them, then that could be a real problem, because it the amount Uh, that, that value is present rather than knowing its, uh, rough prevalence.

So I think, it can cause plan flips and I think there are a couple of others as well. so I do, think we have a few tools and you, you mentioned the enable ones. They, most people discourage their use in the same way they discourage the use of hints, but we do have those tools available to us in extreme circumstances.

[00:21:47] Nikolay: Right. Well, yes, I wouldn't recommend a change of globe, a global change of enable underscore something, except some very like weird cases, which is not, not common these days. But again, let me, like, I have three goals in my head, three big goals of, uh, for, , linear hints or like advanced tuning. Uh, by the way, like, I will try to convince everyone that actually like there's basis, basic thought, uh, more control abilities is actually better.

Of course you can make mistakes and, but like this is, this is meta idea, right? And now three goals, three ideas. First is fix particular. Query, because it behaves wrong, and we like check statistics, we check everything, we check plan, we know it should choose different plan, it happens still sometimes, not super often.

The planner is improved already, compared to 15 years ago, for example. Second goal is predictable behavior, and, uh, Hints would be very, , high maintenance solution to it. This idea that Aurora implemented, obviously, looking at enterprise, uh, database systems. It's great. Like, you have baseline, you know, like, you have approved, pre approved workflow for plans, and you know...

Flip cannot happen, because if plan changes, you will just get notification, alert about it, but it won't be applied yet until you approve it. This is great, like, full control. I think this is very good thing to have in the future, probably for community Postgres as well. Really good problem to solve, like, full predictability for plans.

No, plan, flip, problem fully solved, right? Because...

[00:23:42] Michael: I'm not sure about fully, like sometimes the plan won't be available anymore. I think, like, I think there are exceptions, but I, but way more control. I agree.

[00:23:49] Nikolay: but this is depends, this depends also already how this particular, on implementation of this. But the idea is very good, I mean, I know a lot of people, especially closer to management who do want predictability. It's not a... A toy or a joke to, , have something down if you have a lot of money involved every minute or every second and Postgres is in the center and PlanFlip can cost you a lot of money, right?

So predictability is super important and by default we don't have to. Good way to do it right now, unfortunately. And third, very good and interesting case is, troubleshooting, like, research of the plan behavior for particular, or a few queries, and you want to understand, alternative plans, you want to see how it, how it's working.

Official way, like, okay, we have sequential scan, we don't know why, we want, like, unfortunately, when you ask the planner to provide the plan, Using explain, even without execution. You don't, like, the structure you can see without execution really quickly, unless merge, join, and vault in some cases, and it takes a minute, right?

[00:25:03] Michael: Yeah, I completely agree. We have things like hyper PG, for example, if we want to like check between two indexes, but without those, even the enable parameters don't help us because we can't not use a certain index. We have to drop one and recreate another one. I think, I think you're completely right that around that troubleshooting, it could be extra helpful as well.

[00:25:22] Nikolay: by the way, doesn't Hyper PG support this, like, let's imagine there is no such index, let's... Try to turn it off. I don't think like so, but again, like let me finish my thought.

so you need to explore particular query, how it behaves and how it would behave if under certain circumstances. In this case, official way to do it, for example, you see sequential scan, but you know there is index.

Why this index is not used? Uh, explain command provides only single the best plan. The chosen plan, right? What planner chooses, but you don't see the second best, the third best, unfortunately, and there is no good way to see them. In some cases, I would like to see like top five options or something, because I would see, okay, this is why, Planner thinks the sequential scan is better because it thinks cost is better versus like index scan, which has slightly bigger cost.

It gives me some understanding. Maybe I will go and check a random page cost and see it's default four. That's why let's go down to one and match sec page cost, sequential page cost. In this case, index scan probably will win. So in this case, additional ways to control behavior and see. official ways, okay, we say enable sex scan to off, meaning it's actually not off, but it's just has a huge tax, like, penalty, right?

It has huge penalty, like, absolutely huge, and it's become, it's becoming much less attractive. And then probably we'll see IndexScan IndexScan in this case. But it would be good to have, maybe it's not hints, I don't know, but it would be good to have a more fine grained way to control this behavior. And maybe I'm talking just because, like, maybe I'm talking about extending explain command with ability to see multiple plans and not only the best, the chosen plan.

But in general, this is where hints can help. You to study the behavior of the planner for particular queries, but there is a big caveat if you start using, pgPlanHint. Extension. Hint plans. Sorry, I always mix. Sorry. So if you start using it in larger teams, in larger teams, right, at some point people will go to you and say, you know, it's great, but why production doesn't have it?

I already put proper hints into the code. So, I mean, if you, if you use it in lower environments. For yourself, it's fine. If it's a small team, it's fine, but if it's a larger team, then you need to explain why it exists only in lower environments and it's not available in production.

[00:28:06] Michael: Interesting.

[00:28:07] Nikolay: Yeah, I had this

situation.

[00:28:09] Michael: yeah, it didn't sound hypothetical. I, a lot of these things come up in the mailing list over and over again. Some of the reasons I liked for them pushing back was that it would, so this would reduce, so by implementing hints in Postgres, or at least these comment level hints, it would...

Divert resources away from other planner work, improving the root causes, makes some sense. another one was that it would reduce the Reporting of issues. So if people have these optimizer bugs and they're working around them, that reduces the ability of the core team to fix those, which is interesting.

But then the one I disagreed with, I think is the one you're alluding to, which is if we put it in, it will be used inappropriately. So people will

[00:28:52] Nikolay: Of

[00:28:52] Michael: fix. And so that's, it's a good reason, except I think I agree with you that. I think it's better to give people these sharp tools, even if they risk cutting themselves with them.

because there are other people who will use them really well. And you'd be surprised what people can create with them. But so it's, I do, I do see both sides on that. On that argument, but I think we've also before we finish, I think we've also missed at least three, maybe four other tools we have available to us to work around this.

And these are, I think they often get called optimization fences. So things that normally stop the planner being able to do clever things, which, but mean, therefore we can, uh, kind of force the plan in a certain direction. So I've, um, people use temp tables sometimes, CTEs with, with materialized.

Um, people use offset zero. That's another one. Like, so you've got

[00:29:46] Nikolay: yeah, yeah, old one, yeah,

[00:29:48] Michael: yeah, old one, but also it's been, it's been so prevalently used, that there've even been discussions that we, we almost can't remove the fact that it's an optimization event because it's being relied on now as a hint, which is quite funny.

And even one you, you brought up a while back, but, um, materialized views allowing you to then kind of. Uh, index on columns on multiple tables, for example, also means we can do statistics on multiple tables. Like if we, if we extend that a little bit. Yeah, I know. But all of those are extra tools we have,

[00:30:19] Nikolay: and they are available everywhere, yes, that's good, because some Like, not popular extensions are not available everywhere on managed Postgres installations, right, RDS or something. These, you mentioned very standard and core things, like, everyone can use them. So, yeah, I like, I still like that we have, like, CTE, Optimization Fence, sometimes you'll just, maybe even exploring, like if you have complex query, you start splitting it to stages and thinking, okay, I want to take control of, on planar behavior to understand why it's so slow, because it feels that there's a way it should not be slow, and you just start writing with.

Blah, blah, as materialized, and the stages are, have optimization fence between them, so you have materialization after each step, and independent, basically independent query behavior for each step. This is good. I mean, it's also good it's not default behavior now, but ability to have it, like ability to, if you know what you're doing, you just do it and that's good.

it makes SQL, of course, much less declarative because you already start programming, right? Because You know, recursive CTE is Turing complete. You can program a lot of things using recursive CTE, and we do it sometimes. It's not already... Declarative concept is broken here, but again, like, I'm in favor of having as much control knobs as possible, probably hidden behind the warning expert mode,

[00:31:58] Michael: Yeah. Well, even in the SQL server, I was reading some of the other, um, database. Docs around this, and SQL Servers says, uh, because the SQL Server optimizer typically selects the best execution plan for a query, we recommend only using hints as a last resort for experienced developers and

[00:32:15] Nikolay: That's a good point. Good

[00:32:17] Michael: So it comes with that warning right at the top of the docs.

[00:32:21] Nikolay: Yeah, that's a good point. But, uh, it's better to have it this last resort because it sucks when you cannot fix, you know, it should be there, but it's not so like, it's not, again, it's not happening too often these days. It happened more often, , back in the past, like, plainer behavior is improving. So, but still,

[00:32:41] Michael: actually wrote down some of the version dates before we finished. So default statistics target was added in 7. 3, function costs and rows. So you can now, when you, when you write a new function, you can tell it how much cost it should assign to it and how many rows are expected to be returned. That was added in 8.

3, I think after some of the discussions around hints, um, same, same dates as the version I was looking at and then extended statistics was version 10, so that was only six years ago, which is pretty cool.

[00:33:12] Nikolay: So if, like, maybe as a bottom line, yeah. If we consider hints in wide sense, Postgres has a lot of ways for hinting, hinting already in narrow sense. Like this comments oracle style. It has, uh, pg uh, plan, hint, hint,

[00:33:32] Michael: close. Yep.

[00:33:35] Nikolay: Yeah. I will never, uh, pronounce it right, but it should be used as again, like did or in, or either for research or, uh, as last resort.

But, uh, what? I think Postgres lacks, in my opinion, it's not hints, but three things. Ability to have it.

Simple feature, relatively simple feature. And I know many projects which would benefit from having it. Second is, uh, this... Ability to see from explain, to see second best, third best, awesome. I know, like, MongoDB has something like that, right?

[00:34:22] Michael: I don't know. I

[00:34:23] Nikolay: Yeah, well, maybe

[00:34:24] Michael: complex than you think.

[00:34:25] Nikolay: Oh, okay, okay, yes, I understand, like, genetic optimizer involved and so on. I understand that. And finally, this, uh, what Aurora has, it would be great to have, of course. In, in, in, uh, in the future. In ideal world, I, I see Postgres having all these three things and, uh, if someone is looking for ideas to work on something, these, these three directions are great to, great to work on for community Postgres.

[00:34:55] Michael: Wonderful. Lovely summary. Thank you.

[00:34:58] Nikolay: Good. So, okay. I think we covered this topic quite well. I like such topics because they lead to, , discussions because like, you know, there are some camps I'm. I'm not sure in which camp I am, because I want hints, but I don't want them to be used in wrong way. So, so, yeah, I just want more ability. A wider range of control knobs, you know. Okay, so maybe that's it, right?

[00:35:27] Michael: think so. Thanks everybody and catch you next week.

[00:35:30] Nikolay: Thank you. Don't forget to share with your colleagues and friends who work with Postgres as well. Bye bye.