Josh Berkus <josh@agliodbs.com> writes:
>> The explanation is in
>> http://archives.postgresql.org/message-id/20130910132133.GJ1024477%40alap2.anarazel.de
>>
>> The referenced commit introduced a planner feature. Funnily you seem to
>> have been the trigger for it's introduction ;)
> Oh, crap, the "off the end of the index" optimization?
> It's the story of our lives: we can't optimize anything without
> deoptimizing something else. Dammit.
I wonder if we could ameliorate this problem by making
get_actual_variable_range() use SnapshotDirty rather than either
SnapshotNow (as it does in released versions) or the active snapshot (as
it does in HEAD). We discussed that idea in the SnapshotNow removal
thread, see eg
http://www.postgresql.org/message-id/CA+TgmoZ_q2KMkxZAoRxRHB7k1tOmjVjQgYt2JuA7=U7QZoLxNw@mail.gmail.com
In that thread I claimed that a current MVCC snapshot was the most
appropriate thing, which it probably is; but the argument for it isn't so
strong that I think we should be willing to spend unbounded effort to get
that version of the column min/max rather than some other approximation.
The best objection to it that I can see is Robert's security concern about
leakage of uncommitted values --- but I don't think that holds a huge
amount of water either. We already try to limit the visibility of the
regular elements of the histogram, why are these not-yet-committed values
significantly more of an issue?
regards, tom lane
