| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Zheng Li <zhengli10(at)gmail(dot)com>, Jim Nasby <nasbyj(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Reducing power consumption on idle servers |
| Date: | 2023-01-24 20:39:39 |
| Message-ID: | 2316942.1674592779@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> Yeah, I definitely want to fix it. I just worry that 60s is so long
> that it also needs that analysis work to be done to explain that it's
> OK that we're a bit sloppy on noticing when to wake up, at which point
> you might as well go to infinity.
Yeah. The perfectionist in me wants to say that there should be
explicit wakeups for every event of interest, in which case there's
no need for a timeout. The engineer in me says "but what about bugs?".
Better a slow reaction than never reacting at all. OTOH, then you
have to have a discussion about whether 60s (or any other
ice-cap-friendly value) is an acceptable response time even in the
presence of bugs.
It's kind of moot until we've reached the point where we can
credibly claim to have explicit wakeups for every event of
interest. I don't think we're very close to that today, and
I do think we should try to get closer. There may come a point
of diminishing returns though.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2023-01-24 21:11:20 | Re: run pgindent on a regular basis / scripted manner |
| Previous Message | David G. Johnston | 2023-01-24 20:39:35 | Re: Making Vars outer-join aware |