From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "McAlister, Grant" <grant(at)amazon(dot)com>, "Mlodgenski, Jim" <mlodj(at)amazon(dot)com>, "Nasby, Jim" <nasbyj(at)amazon(dot)com>, "Hsu, John" <hsuchen(at)amazon(dot)com> |
Subject: | Re: partial heap only tuples |
Date: | 2021-04-20 00:41:42 |
Message-ID: | CAH2-Wznh7J2Ey6dshcyjdkH5taFz4V6bN2rJL5MH6xyOuo=9mw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 19, 2021 at 5:09 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > A diversity of strategies with fallback behavior is sometimes the best
> > strategy. Don't underestimate the contribution of rare and seemingly
> > insignificant adverse events. Consider the lifecycle of the data over
>
> That is an intersting point --- we often focus on optimizing frequent
> operations, but preventing rare but expensive-in-aggregate events from
> happening is also useful.
Right. Similarly, we sometimes focus on adding an improvement,
overlooking more promising opportunities to subtract a disimprovement.
Apparently this is a well known tendency:
I believe that it's particularly important to consider subtractive
approaches with a complex system. This has sometimes worked well for
me as a conscious and deliberate strategy.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-04-20 00:44:31 | Re: when the startup process doesn't |
Previous Message | Thomas Munro | 2021-04-20 00:38:11 | Re: when the startup process doesn't |