From: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Track the amount of time waiting due to cost_delay |
Date: | 2024-06-11 21:04:29 |
Message-ID: | E12435E2-5FCA-49B0-9ADB-0E7153F95E2D@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> I'm struggling to think of a scenario in which the number of waits would be
>> useful, assuming you already know the amount of time spent waiting. Even
>> if the number of waits is huge, it doesn't tell you much else AFAICT. I'd
>> be much more likely to adjust the cost settings based on the percentage of
>> time spent sleeping.
> This is also how I see it.
I think it may be useful for a user to be able to answer the "average
sleep time" for a vacuum, especially because the vacuum cost
limit and delay can be adjusted on the fly for a running vacuum.
If we only show the total sleep time, the user could make wrong
assumptions about how long each sleep took and they might
assume that all sleep delays for a particular vacuum run have been
uniform in duration, when in-fact they may not have been.
Regards,
Sami
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2024-06-11 21:31:39 | Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions |
Previous Message | Tom Lane | 2024-06-11 20:59:14 | Re: Keeping track of buildfarm animals' personality |