Fix btree stop-at-nulls logic properly.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 2 Nov 2011 21:53:49 +0000 (17:53 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 2 Nov 2011 21:53:49 +0000 (17:53 -0400)
commit882368e854b6f094f94aca292f390bbd9f44359b
tree3516959d9078a761a223aa540c0ef153d3461f92
parent750f70b0fe91258f9f99b1d04a510e5b035e9249
Fix btree stop-at-nulls logic properly.

As pointed out by Naoya Anzai, my previous try at this was a few bricks
shy of a load, because I had forgotten that the initial-positioning logic
might not try to skip over nulls at the end of the index the scan will
start from.  We ought to fix that, because it represents an unnecessary
inefficiency, but first let's get the scan-stop logic back to a safe
state.  With this patch, we preserve the performance benefit requested
in bug #6278 for the case of scanning forward into NULLs (in a NULLS
LAST index), but the reverse case of scanning backward across NULLs
when there's no suitable initial-positioning qual is still inefficient.
src/backend/access/nbtree/nbtutils.c
src/test/regress/expected/create_index.out
src/test/regress/sql/create_index.sql