Avoid scanning nulls at the beginning of a btree index scan.
If we have an inequality key that constrains the other end of the index,
it doesn't directly help us in doing the initial positioning ... but it
does imply a NOT NULL constraint on the index column. If the index stores
nulls at this end, we can use the implied NOT NULL condition for initial
positioning, just as if it had been stated explicitly. This avoids wasting
time when there are a lot of nulls in the column. This is the reverse of
the examples given in bugs #6278 and #6283, which were about failing to
stop early when we encounter nulls at the end of the indexscan.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/1a77f8b63d159b88ceb6245fcb5e81a7f9ac9a22
Modified Files
--------------
src/backend/access/nbtree/nbtsearch.c | 67 +++++++++++++++++++++++++++++---
1 files changed, 60 insertions(+), 7 deletions(-)
