=?UTF-8?Q?Fr=c3=a9d=c3=a9ric_Yhuel?= <frederic.yh...@dalibo.com> writes: > On 10/24/22 17:26, Frédéric Yhuel wrote: >> When studying the weird planner issue reported here [1], I came up with >> the attached patch. It reduces the probability of calling >> get_actual_variable_range().
> This isn't very useful anymore thanks to this patch: > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=9c6ad5eaa957bdc2132b900a96e0d2ec9264d39c I hadn't looked at this patch before, but now that I have, I'm inclined to reject it anyway. It just moves the problem around: now, instead of possibly doing an unnecessary index probe at the right end, you're possibly doing an unnecessary index probe at the left end. It also looks quite weird compared to the normal coding of binary search. I wonder if there'd be something to be said for leaving the initial probe calculation alone and doing this: else if (probe == sslot.nvalues - 1 && sslot.nvalues > 2) + { + /* Don't probe the endpoint until we have to. */ + if (probe > lobound) + probe--; + else have_end = get_actual_variable_range(root, vardata, sslot.staop, collation, NULL, &sslot.values[probe]); + } On the whole though, it seems like a wart. regards, tom lane
