On Mon, Jan 2, 2017 at 9:28 AM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote: > > > On Mon, Jan 2, 2017 at 8:52 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> >> >> I think there is some chance that such a change could induce >> regression for the cases when there are many index columns or I think >> even when index is on multiple columns (consider index is on first and >> eight column in a ten column table). >> > > I don't see that as a problem because the routine only checks for columns > that are passed as "interesting_cols". >
Right, but now it will evaluate for all interesting_cols whereas previously it would just stop at first if that column is changed.
Ah ok. I read your comment "consider index is on first and
eight column in a ten column table" as s/eight/eighth. But may be you're referring to
the case where there is an index on eight or nine columns of a ten column table.
You're right. That's an additional cost as Alvaro himself explained in the original
post. But both indirect indexes and WARM needs to know information about all
modified columns. So assuming either of these patches are going to make it,
we've to bear that cost. Having said that, given that attributes are usually cached,
the cost may not be significant since for non-HOT updates, the
attributes will be later fetched anyways while preparing index tuples. So we're
probably doing that work in advance.
Obviously, I'm not against doing additional performance tests to ensure that the
cost is not significant, especially if neither indirect indexes nor WARM gets