Greetings, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > On 2024-Feb-26, Stephen Frost wrote: > > Here's an updated patch which tries to improve on the wording a bit by > > having it be a bit more consistent. Would certainly welcome feedback on > > it though, of course. This is a tricky bit of language to write and > > a complex optimization to explain. > > Should we try to explain what is a "summarizing" index is? Right now > the only way to know is to look at the source code or attach a debugger > and see if IndexAmRoutine->amsummarizing is true. Maybe we can just say > "currently the only in-core summarizing index is BRIN" somewhere in the > page. (The patch's proposal to say "... such as BRIN" strikes me as too > vague.)
Not sure about explaining what one is, but I'd be fine adding that language. I was disappointed to see that there's no way to figure out the value of amsummarizing for an access method other than looking at the code. Not as part of this specific patch, but I'd generally support having a way to that information at the SQL level (or perhaps everything from IndexAmRoutine?). Attached is an updated patch which drops the 'such as' and adds a sentence mentioning that BRIN is the only in-core summarizing index. Thanks! Stephen
From 131f83868b947b379e57ea3dad0acf5a4f95bca8 Mon Sep 17 00:00:00 2001 From: Stephen Frost <sfr...@snowman.net> Date: Mon, 26 Feb 2024 17:17:54 -0500 Subject: [PATCH] docs: Update HOT update docs for 19d8e2308b Commit 19d8e2308b changed when the HOT update optimization is possible but neglected to update the Heap-Only Tuples (HOT) documentation. This patch updates that documentation accordingly. Author: Elizabeth Christensen Reviewed-By: Stephen Frost, Alvaro Herrera Backpatch-through: 16 Discussion: https://postgr.es/m/CABoUFXRjisr58Ct_3VsFEdQx+fJeQTWTdJnM7XAp=8mubto...@mail.gmail.com --- doc/src/sgml/storage.sgml | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml index 3ea4e5526d..f2bb0283ae 100644 --- a/doc/src/sgml/storage.sgml +++ b/doc/src/sgml/storage.sgml @@ -1097,8 +1097,13 @@ data. Empty in ordinary tables.</entry> <itemizedlist> <listitem> <para> - The update does not modify any columns referenced by the table's - indexes, including expression and partial indexes. + The update only modifies columns which are not referenced by the + table's indexes or are only referenced by summarizing indexes and + does not update any columns referenced by the table's + non-summarizing indexes, including expression and partial + non-summarizing indexes. The only summarizing index in the core + <productname>PostgreSQL</productname> distribution is + <acronym>BRIN</acronym>. </para> </listitem> <listitem> @@ -1114,7 +1119,8 @@ data. Empty in ordinary tables.</entry> <itemizedlist> <listitem> <para> - New index entries are not needed to represent updated rows. + New index entries are not needed to represent updated rows, however, + summary indexes may still need to be updated. </para> </listitem> <listitem> @@ -1130,11 +1136,10 @@ data. Empty in ordinary tables.</entry> </para> <para> - In summary, heap-only tuple updates can only be created - if columns used by indexes are not updated. You can - increase the likelihood of sufficient page space for - <acronym>HOT</acronym> updates by decreasing a table's <link - linkend="reloption-fillfactor"><literal>fillfactor</literal></link>. + In summary, heap-only tuple updates can only be created if columns used by + non-summarizing indexes are not updated. You can increase the likelihood of + sufficient page space for <acronym>HOT</acronym> updates by decreasing + a table's <link linkend="reloption-fillfactor"><literal>fillfactor</literal></link>. If you don't, <acronym>HOT</acronym> updates will still happen because new rows will naturally migrate to new pages and existing pages with sufficient free space for new row versions. The system view <link -- 2.34.1
signature.asc
Description: PGP signature
