<p dir="ltr"><br /> On 6 Apr 2015 09:17, "Jim Nasby" <<a
href="mailto:Jim.Nasby@bluetreble.com">Jim.Nasby@bluetreble.com</a>>wrote:<br /> ><br /> > <br /> > No. You
wouldbe free to set a table as ReadOnly any time you wanted, without scanning anything. All that setting does is
disableany DML on the table.<br /> ><br /> > The Frozen state would only be set by the vacuum code, IFF:<br />
>- The table state is ReadOnly *at the start of vacuum* and did not change during vacuum<br /> > - Vacuum ensured
thatthere were no un-frozen tuples in the table<br /> ><br /> > That does not necessitate 2 scans.<p
dir="ltr">Thisis exactly what I would suggest.<p dir="ltr">Only I would suggest thinking of it in terms of two
orthogonalboolean flags rather than three states. It's easier to reason about whether a table has a specific property
thantrying to control a state machine in a predefined pathway.<p dir="ltr">So I would say the two flags are: <br />
READONLY:guarantees nothing can be dirtied<br /> ALLFROZEN: guarantees no unfrozen tuples are present<p dir="ltr">In
practiceyou can't have the later without the former since vacuum can't know everything is frozen unless it knows nobody
isinserting. But perhaps there will be cases in the future where that's not true.<p dir="ltr">Incidentally there are
numberof other optimisations tat over had in mind that are only possible on frozen read-only tables:<p dir="ltr">1)
Compression:compress the pages and pack them one after the other. Build a new fork with offsets for each page.<p
dir="ltr">2)Automatic partition elimination where the statistics track the minimum and maximum value per partition (and
numberof tuples) and treat then as implicit constraints. In particular it would magically make read only empty parent
partitionsbe excluded regardless of the where clause.
