Bruno Wolff III <bruno@xxxxxxxx> writes: > I suspect it wasn't intended to be a full table scan. But rather a sequential > scan until it found a matching row. If the data in the table is ordered by > by id, this strategy may not work out well. Where as if the data is randomly > ordered, it would be expected to find a match quickly. Right. You can see from the differential in the estimates for the SeqScan and the Limit nodes that the planner is not expecting the seqscan to run to completion, but rather to find a matching row quite quickly. There is not anything in there that considers whether the table's physical order is so nonrandom that the search will take much longer than it would given uniform distribution. It might be possible to do something with the correlation statistic in simple cases ... regards, tom lane
