Re: partial heap only tuples

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:

https://www.scientificamerican.com/article/our-brain-typically-overlooks-this-brilliant-problem-solving-strategy/

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

In response to

Browse pgsql-hackers by date

  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