On Sat, Jul 23, 2022 at 12:12:38PM -0700, David G. Johnston wrote:
> I concur, suggesting the following:
>
> "Specifically, updates result in multiple rows versions (tuples) existing on
> the table."
See my reply to Peter G. about tuples.
> "There is sufficient free space on the page containing the old tuple for the
> updated tuple."
Same.
> "Old tuples can be completely removed..."
It is really old row versions, not old tuples since tuples, in my mind,
don't have a chain of versions. There are cannot-be-viewed-by-anyone
tuples, but that is not the point here.
> Overall, I think that this is suitable to commit, and I don't want to
> make too much of a fuss. It's great that we're doing this.
>
>
>
> Agreed. The other suggestion listed are not clear-cut winners in my mind.
>
> The following, though, seems to just come out of nowhere. It would be better
> setup as a "(See <link> for why this is possible.)" instead of dropping "page
> item identifiers" on the reader.
>
> + This removal is possible because indexes
> + do not reference their <link linkend="storage-page-layout">page
> + item identifiers</link>.
I added parentheses around that.
>
> As a related thought, this has done a great job of being usable for a DBA
> operating at a high-level of system knowledge and interaction. I don't think
> burying it in storage.sgml is desirable, Maybe "Performance Tips" under "Avoid
> Unnecessary Indexes" (yes, a bit of a stretch, but nothing else seems to fit
> better, except maybe in concurrency control since we are discussing overcoming
> the limitation of our concurrency control choice.
Uh, not sure. Anyone else have an opinion?
> Summary paragraph:
> "can only happen if" => "can only be created if"
Yes, good point.
Updated patch attached.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson