On 2013-11-29 01:16:39 -0500, Robert Haas wrote:
> On Thu, Nov 14, 2013 at 8:46 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > [ new patches ]
>
> Here's an updated version of patch #2. I didn't really like the
> approach you took in the documentation, so I revised it.
Fair enough.
> Apart from that, I spent a lot of time looking at
> HeapSatisfiesHOTandKeyUpdate. I'm not very happy with your changes.
> The idea seems to be that we'll iterate through all of the HOT columns
> regardless, but that might be very inefficient. Suppose there are 100
> HOT columns, the last one is the only key column, and only the first
> one has been modified. Once we look at #1 and determine that it's not
> HOT, we should zoom forward and skip over the next 98, and only look
> at the last one; your version does not behave like that.
Well, the hot bitmap will only contains indexed columns, so for that's
only going to happen if there's actually indexes over all those
columns. And in that case it seems unlikely that the performance
of that routine matters.
That said, keeping the old performance characteristics seems like a good
idea to me. Not sure anymore why I changed it that way.
> I've taken a crack at rewriting
> this logic, and the result looks cleaner and simpler to me, but I
> haven't tested it beyond the fact that it passes make check. See what
> you think.
Hm. I think it actually will not abort early in call cases either, but
that looks fixable. Imagine what happens if id_attrs or key_attrs is
empty, ISTM that we'll check all hot columns in that case.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services