Robert Haas <robertmh...@gmail.com> writes: > I don't think this is safe at all. Wait events can only bracket > individual operations, like the reads of the individual index blocks, > not report on which phase of a larger operation is in progress. If we > try to make them do the latter, we will have a hot mess on our hands.
Agreed. > What we need is a solution that avoids reading an unbounded number of > tuples under any circumstances. I previously suggested using > SnapshotAny here, but Tom didn't like that. I'm not sure if there are > safety issues there or if Tom was just concerned about the results > being misleading. Either way, maybe there's some variant on that theme > that could work. For instance, could we teach the index scan to stop > if the first 100 tuples that it finds are all invisible? Or to reach > at most 1 page, or at most 10 pages, or something? A hard limit on the number of index pages examined seems like it might be a good idea. > If we don't find a > match, we could either try to use a dead tuple, or we could just > return false which, I think, would end up using the value from > pg_statistic rather than any updated value. Yeah, the latter seems like the best bet. Returning a definitely-dead value could be highly misleading. In the end this is meant to be an incremental improvement on what we could get from pg_statistic, so it's reasonable to limit how hard we'll work on it. If we do install such a thing, should we undo any of the previous changes that backed off the reliability of the result? regards, tom lane