On Fri, Mar 10, 2017 at 11:37 PM, Alvaro Herrera
> Robert Haas wrote:
>> On Wed, Mar 8, 2017 at 2:30 PM, Alvaro Herrera <alvhe...@2ndquadrant.com>
>> > 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
> 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.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: