On Sat, Jul 23, 2022 at 8:51 AM Bruce Momjian <bruce@momjian.us> wrote:
> Good points. I have updated the attached patch and URL to mention that
> HOT rows are _completely_ removed, and why that is possible, and I
> clarified the page item identifier mention.
I think that this version looks very good, but I do have some minor notes:
* You wrote "Specifically, updates cause additional rows to be added to tables."
Perhaps this could be rephrased: "Specifically, updates add new
physical tuples to tables to represent each new version."
I think that the term "row" should only refer to the simple/abstract
idea of a row from a table, while the term tuple should be preferred
when referring to a physical embodiment of a row, like one version of
a row. Perhaps it's worth following that convention across the board
here (not just in this sentence that I have highlighted).
I concur, suggesting the following:
"Specifically, updates result in multiple rows versions (tuples) existing on the table."
"There is sufficient free space on the page containing the old tuple for the updated tuple."
"Old tuples can be completely removed..."
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>.
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.
Summary paragraph:
"can only happen if" => "can only be created if"
David J.