Re: [BUG] Autovacuum not dynamically decreasing cost_limit and cost_delay
On Mon, Jan 23, 2023 at 12:33 PM Alvaro Herrera wrote: > On 2021-Feb-08, Mead, Scott wrote: > > > Hello, > >I recently looked at what it would take to make a running autovacuum > > pick-up a change to either cost_delay or cost_limit. Users frequently > > will have a conservative value set, and then wish to change it when > > autovacuum initiates a freeze on a relation. Most users end up > > finding out they are in ‘to prevent wraparound’ after it has happened, > > this means that if they want the vacuum to take advantage of more I/O, > > they need to stop and then restart the currently running vacuum (after > > reloading the GUCs). > > Hello, I think this has been overlooked, right? I can't find a relevant > commit, but maybe I just didn't look hard enough. I have a feeling that > this is something that we should address. If you still have the cycles, > please consider posting an updated patch and creating a commitfest > entry. > Thanks! Yeah, I should be able to get this together next week. > > Thanks > > -- > Álvaro Herrera PostgreSQL Developer — > https://www.EnterpriseDB.com/ > "Someone said that it is at least an order of magnitude more work to do > production software than a prototype. I think he is wrong by at least > an order of magnitude." (Brian Kernighan) > -- -- Scott Mead *sc...@meads.us *
Re: [BUG] Autovacuum not dynamically decreasing cost_limit and cost_delay
of worker's limit calculation says: > > /* > * We put a lower bound of 1 on the cost_limit, to avoid division- > * by-zero in the vacuum code. Also, in case of roundoff trouble > * in these calculations, let's be sure we don't ever set > * cost_limit to more than the base value. > */ > worker->wi_cost_limit = Max(Min(limit, > worker->wi_cost_limit_base), > 1); > > If we use the max cost_limit as the upper bound here, the worker's > limit could unnecessarily be higher than the base value in case of > roundoff trouble? I think that the problem here is rather that we > don't update wi_cost_limit_base and wi_cost_delay when rebalancing the > cost. > Currently, vacuum always limits you to the cost_limit_base from the time that your vacuum started. I'm not sure why, I don't believe it's rounding related because the rest of the rebalancing code works properly. ISTM that looking simply allowing the updated cost_limit is a simple solution since the rebalance code will automatically take it into account. > > Regards, > > -- > Masahiko Sawada > EDB: https://www.enterprisedb.com/ > > > -- -- Scott Mead *sc...@meads.us *
Re: proposal: alternative psql commands quit and exit
On Sat, Dec 9, 2017 at 1:27 AM, Rok Kralj wrote: > Most popular questions on every topic are the simplest ones. Imagine a > parallel universe where this patch is contained in the codebase - I argue > this question about exiting the repl still is the top one, albeit with less > votes. > > On Sat, Dec 9, 2017, 11:03 Michael Paquier > wrote: > >> On Sat, Dec 9, 2017 at 3:56 AM, Robert Haas >> wrote: >> > On Fri, Dec 8, 2017 at 8:57 AM, Daniel Vérité" >> wrote: >> >> When looking at the most popular postgres questions on stackoverflow: >> >> >> >> https://stackoverflow.com/questions/tagged/postgresql?sort=votes >> >> >> >> the first one (most up-voted) happens to be: >> >> >> >> "How to exit from PostgreSQL command line utility: psql" >> >> >> >> now at 430k views and 1368 upvotes. >> > >> > Wow, that's pretty crazy. I was going to vote against this proposal, >> > but I think I might change my mind. How can we say that this isn't a >> > problem for users given that data? It's evidently not only *a* >> > problem, but arguably the biggest one. >> >> That's an impressive number, indeed. And an argument about potentially >> doing something. >> > Far less concrete, I can tell you this: Over the last 10 years, I've averaged teaching ~ 2 PG classes per quarter to students from every background: Database (you name it), OS admin, developer, consultant, etc... I have the students use pgbench to generate some data, run some queries and pg_dump it. *EVERY* single class has at least one: postgres=# \dt List of relations Schema | Name | Type | Owner +--+---+-- public | pgbench_accounts | table | postgres public | pgbench_branches | table | postgres public | pgbench_history | table | postgres public | pgbench_tellers | table | postgres (4 rows) postgres=# exit postgres-# pg_dump postgres-# pg_dump postgres-# pg_dump postgres-# pg_dump --help postgres-# ls postgres-# cd postgres-# exit postgres-# quit postgres-# It's not just usability, it's a point of serious frustration for seasoned database people. +1 > -- >> Michael >> >> -- -- Scott Mead Sr. Architect *OpenSCG <http://openscg.com>* http://openscg.com
