Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oFKYh-0003l3-V8 for pgsql-docs@arkaria.postgresql.org; Sat, 23 Jul 2022 19:13:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oFKYf-0000RV-Rd for pgsql-docs@arkaria.postgresql.org; Sat, 23 Jul 2022 19:13:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oFKYf-0000RM-Gc for pgsql-docs@lists.postgresql.org; Sat, 23 Jul 2022 19:13:01 +0000 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oFKYa-0007A9-IQ for pgsql-docs@lists.postgresql.org; Sat, 23 Jul 2022 19:12:59 +0000 Received: by mail-ed1-x52b.google.com with SMTP id g1so9328443edb.12 for ; Sat, 23 Jul 2022 12:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5iV4gUVWNMRwO4Duoo7i2etog2cjb062HceiauXvafQ=; b=YzqmxNvXCv4IXgob7FEjdkvxw+ctDmUuA8kQ/OMxmgT1X3Fn8YXPy3pATpx3B/z+gL 1UmqTtJ27SSyv87Kf91IW7ZsGm58aRbh0lDMAOv77Vfsl0YD+zCqRR6TgNHY/F8s4QY8 ElBZ3rJYdEL0To739BOZLO/6T49OdUnJpc/n3BSci7gHv5+hDDseYEMy1ggr/yDUIazR G9zQkEVWKInasE/hSAu7gDw5MCr9M2eAux0WbnS6/tpVAf6qz7RYvjWgeXTY0IQg7DXZ wt1fJrzuXv0sG04m9TxEl22d9OF9QoHWo7JNUxJ5RfRsZEtj1m8UNzPlegWb7PDdYn1W 1A0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5iV4gUVWNMRwO4Duoo7i2etog2cjb062HceiauXvafQ=; b=55/sSEGqVy96OP7bCYq50BuCFgglRQFtZqmbR8ghotKzVYp0BPxzHM4eAQAJpgQK4Q geIrmQb/SFlkL31y9BQlaOZoz+lYNC5d5anNxxId4DWYUUoaDzETrtyDyqXYb5JoJmoq yVymc7V+fF6TLhxhFzU6vCB5gPnLbvzzcNXYmyWtba/6vIUnE+1ptcZ0Z4nXTOIs5+JZ M3sRyhP5sNRG25tHod51827e4SUD3FCuQJ7gb2Rqis54vyjcWW1P/Ph/vpDx+2Hc/6VX IuJzsvsn01SAPMDXRev+sq0stxG/WRBDMrGVEBjCjQHxCAoyM1zR+jlJ7YjZAnCtvbUG gVwQ== X-Gm-Message-State: AJIora/wQpZ1zWGOhWYVe5dGd24GyTLNDEfDg5YR5O1HIj5uZ2ZdM2Db t78V71oxwVrJULjjrI55+oTKWUefnUkEQjdP4Gw= X-Google-Smtp-Source: AGRyM1tCF5Bt0Jf93NHGIGQtePbs5G3lSbFjKXrXBbLnM8OBcn3vgPMEiIy0Mz6XsWW8EtQSQ9CMeWM06ICN7qlID48= X-Received: by 2002:a05:6402:13c1:b0:43b:e330:9bbf with SMTP id a1-20020a05640213c100b0043be3309bbfmr2257168edx.417.1658603575096; Sat, 23 Jul 2022 12:12:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "David G. Johnston" Date: Sat, 23 Jul 2022 12:12:38 -0700 Message-ID: Subject: Re: documentation on HOT To: Peter Geoghegan Cc: Bruce Momjian , "Jonathan S. Katz" , Pg Docs Content-Type: multipart/alternative; boundary="000000000000eabb5905e47dbcbd" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000eabb5905e47dbcbd Content-Type: text/plain; charset="UTF-8" On Sat, Jul 23, 2022 at 11:34 AM Peter Geoghegan wrote: > On Sat, Jul 23, 2022 at 8:51 AM Bruce Momjian 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 for why this is possible.)" instead of dropping "page item identifiers" on the reader. + This removal is possible because indexes + do not reference their page + item identifiers. 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. --000000000000eabb5905e47dbcbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 23, 2022 at 11:34 AM Peter Geoghegan <pg@bowt.ie> wrote:
= On Sat, Jul 23, 2022 at 8:51 AM Bruce Momjian <bruce@momjian.us> wrote:
> Good points.=C2=A0 I have updated the attached patch and URL to mentio= n 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:<= br>
* You wrote "Specifically, updates cause additional rows to be added t= o 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/abstr= act
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).
<= div>
I concur, suggesting the following:

&= quot;Specifically, updates result in multiple rows versions (tuples) existi= ng on the table."

"There is sufficient f= ree space on the page containing the old tuple=C2=A0for the updated tuple.&= quot;

"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.

<= /blockquote>

Agreed.=C2=A0 The other suggestion listed are= not clear-cut winners in my mind.

The following, tho= ugh, seems to just come out of nowhere.=C2=A0 It would be better setup as a= "(See <link> for why this is possible.)" instead of droppi= ng "page item identifiers" on the reader.

+= =C2=A0 =C2=A0=C2=A0 This removal is possible because indexes
+ =C2=A0 = =C2=A0 do not reference their <link linkend=3D"storage-page-layout&= quot;>page
+ =C2=A0 =C2=A0 item identifiers</link>.

As a related thought, this has done a great job of being usab= le for a DBA operating at a high-level of system knowledge and interaction.= =C2=A0 I don't think burying it in storage.sgml is desirable,=C2=A0 May= be "Performance Tips" under "Avoid Unnecessary Indexes"= (yes, a bit of a stretch, but nothing else seems to fit better, except may= be in concurrency control since we are discussing overcoming the limitation= of our concurrency control choice.

Summary paragraph:=
"can only happen if" =3D> "can only be created i= f"

David J.

--000000000000eabb5905e47dbcbd--