"Simon Riggs" <simon@2ndquadrant.com> wrote:
> > If we combine this with the HOT patch, pages with HOT tuples are probably
> > marked as UNFROZEN because we don't bother vacuuming HOT tuples. They can
> > be removed incrementally and doesn't require explicit vacuums.
>
> Perhaps avoid DSM entries for HOT updates completely?
Yes, if we employ 1bit/page (worth vacuum or not).
Or no if 2bits/page because HOT updates change page states to UNFROZEN.
> > * Enable/Disable DSM tracking per tables
>
> How about a dsm_tracking_limit GUC? (Better name please)
> The number of pages in a table before we start tracking DSM entries for
> it. DSM only gives worthwhile benefits for larger tables anyway, so let
> the user define what large means for them.
> dsm_tracking_limit = 1000 by default.
Sound good. How about small_table_size = 8MB for the variable?
I found that we've already have the value used for truncating
threshold for vacuum. (REL_TRUNCATE_MINIMUM = 1000 in vacuumlazy.c)
I think they have the same purpose in treating of small tables
and we can use the same variable in these places.
> > * Dead Space State Cache
>
> ISTM there should be a point at which DSM is so full we don't bother to
> keep track any longer, so we can drop that information. For example if
> user runs UPDATE without a WHERE clause, there's no point in tracking
> whole relation.
It's a bit difficult. We have to lock DSM *before* we see whether
the table is tracked or not. So we need to cache the tracked state
in the relcache entry, but it requres some works to keep coherency
between cached states and shared states.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center