Josh Berkus <josh@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxx 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
