Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > I wonder if we could ameliorate this problem by making > get_actual_variable_range() use SnapshotDirty > In that thread I claimed that a current MVCC snapshot was the > most appropriate thing, which it probably is; If it reads from the end of the index, won't it actually be reading starting with the value we will obtain using SnapshotDirty, and since the transaction is not yet committed, won't we be making the trip to the heap for each index tuple we read from that point? Why doesn't that make SnapshotDirty more appropriate for purposes of cost estimation? > 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. Since the whole point is to try to get the fastest runtime which produces correct results, I agree even if the other value is in some way more "correct". > 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. It doesn't look like Robert did either, if you read the whole message. In fact, he also questioned why index tuples which would need to be read if we process from that end of the index don't matter for purposes of cost estimation. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
