On Fri, Mar 10, 2017 at 11:37 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Robert Haas wrote: >> On Wed, Mar 8, 2017 at 2:30 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> >> wrote: >> > Not really -- it's a bit slower actually in a synthetic case measuring >> > exactly the slowed-down case. See >> > https://www.postgresql.org/message-id/cad__ougk12zqmwwjzim-yyud1y8jmmy6x9yectnif3rpp6h...@mail.gmail.com >> > I bet in normal cases it's unnoticeable. If WARM flies, then it's going >> > to provide a larger improvement than is lost to this. >> >> Hmm, that test case isn't all that synthetic. It's just a single >> column bulk update, which isn't anything all that crazy, > > The problem is that the update touches the second indexed column. With > the original code we would have stopped checking at that point, but with > the patched code we continue to verify all the other indexed columns for > changes. > > Maybe we need more than one bitmapset to be given -- multiple ones for > for "any of these" checks (such as HOT, KEY and Identity) which can be > stopped as soon as one is found, and one for "all of these" (for WARM, > indirect indexes) which needs to be checked to completion. >
How will that help to mitigate the regression? I think what might help here is if we fetch the required columns for WARM only when we know hot_update is false. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
