| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: VACUUM (DISABLE_PAGE_SKIPPING on) |
| Date: | 2020-11-18 02:04:18 |
| Message-ID: | 20201118020418.GA13408@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2020-Nov-17, Simon Riggs wrote:
> As an additional optimization, if we do find a row that needs freezing
> on a data block, we should simply freeze *all* row versions on the
> page, not just the ones below the selected cutoff. This is justified
> since writing the block is the biggest cost and it doesn't make much
> sense to leave a few rows unfrozen on a block that we are dirtying.
Yeah. We've had ealier proposals to use high and low watermarks: if any
tuple is past the high watermark, then freeze all tuples that are past
the low watermark. However this is ancient thinking (prior to
HEAP_XMIN_FROZEN) and we don't need the low watermark to be different
from zero, since the original xid is retained anyway.
So +1 for this idea.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | torikoshia | 2020-11-18 02:04:34 | [doc] adding way to examine the plan type of prepared statements |
| Previous Message | Michael Paquier | 2020-11-18 02:00:28 | Re: abstract Unix-domain sockets |