From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Subject: | Re: New strategies for freezing, advancing relfrozenxid early |
Date: | 2022-09-15 07:09:44 |
Message-ID: | CAFBsxsGMYnVnnGMDX4pYTTxsuRcXbKJipXve9BFarwHj_h8iyg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 14, 2022 at 11:33 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Wed, Sep 14, 2022 at 3:18 AM John Naylor
> > Furthermore, it doesn't have to anticipate the maximum size, so there
> > is no up front calculation assuming max-tuples-per-page, so it
> > automatically uses less memory for less demanding tables.
>
> The final number of TIDs doesn't seem like the most interesting
> information that VM snapshots could provide us when it comes to
> building the dead_items TID data structure -- the *distribution* of
> TIDs across heap pages seems much more interesting. The "shape" can be
> known ahead of time, at least to some degree. It can help with
> compression, which will reduce cache misses.
My point here was simply that spilling to disk is an admission of
failure to utilize memory efficiently and thus shouldn't be a selling
point of VM snapshots. Other selling points could still be valid.
--
John Naylor
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2022-09-15 07:55:37 | Re: Improve description of XLOG_RUNNING_XACTS |
Previous Message | Kyotaro Horiguchi | 2022-09-15 06:52:10 | Re: ICU for global collation |