Hi, Peter: Happy New Year. For v12-0001-Pass-down-logically-unchanged-index-hint.patch
+ if (hasexpression) + return false; + + return true; The above can be written as return !hasexpression; The negation is due to the return value from index_unchanged_by_update_var_walker() is inverse of index unchanged. If you align the meaning of return value from index_unchanged_by_update_var_walker() the same way as index_unchanged_by_update(), negation is not needed. For v12-0002-Add-bottom-up-index-deletion.patch : For struct xl_btree_delete: + /* DELETED TARGET OFFSET NUMBERS FOLLOW */ + /* UPDATED TARGET OFFSET NUMBERS FOLLOW */ + /* UPDATED TUPLES METADATA (xl_btree_update) ARRAY FOLLOWS */ I guess the comment is for illustration purposes. Maybe you can write the comment in lower case. +#define BOTTOMUP_FAVORABLE_STRIDE 3 Adding a comment on why the number 3 is chosen would be helpful for people to understand the code. Cheers On Wed, Dec 30, 2020 at 6:55 PM Peter Geoghegan <p...@bowt.ie> wrote: > On Wed, Dec 9, 2020 at 5:12 PM Peter Geoghegan <p...@bowt.ie> wrote: > > Attached is v11, which cleans everything up around the tableam > > interface. There are only two patches in v11, since the tableam > > refactoring made it impossible to split the second patch into a heapam > > patch and nbtree patch (there is no reduction in functionality > > compared to v10). > > Attached is v12, which fixed bitrot against the master branch. This > version has significant comment and documentation revisions. It is > functionally equivalent to v11, though. > > I intend to commit the patch in the next couple of weeks. While it > certainly would be nice to get a more thorough review, I don't feel > that it is strictly necessary. The patch provides very significant > benefits with certain workloads that have traditionally been > considered an Achilles' heel for Postgres. Even zheap doesn't provide > a solution to these problems. The only thing that I can think of that > might reasonably be considered in competition with this design is > WARM, which hasn't been under active development since 2017 (I assume > that it has been abandoned by those involved). > > I should also point out that the design doesn't change the on-disk > format in any way, and so doesn't commit us to supporting something > that might become onerous in the event of somebody else finding a > better way to address at least some of the same problems. > > -- > Peter Geoghegan >
