pre-7.3 pg_dump archive files: namespace isn't there, and in some cases
te->tag may already be quotified. Per report from Alan Pevec and
followup testing.
< BY col {DESC} LIMIT 1. Completing this item involves making this
> BY col {DESC} LIMIT 1. Completing this item involves doing this
< invalidated if anyone modifies the table.
<
> invalidated if anyone modifies the table. Another idea is to
> get a count directly from a unique index, but for this to be
> faster than a sequential scan it must avoid access to the heap
> to obtain tuple visibility information.
>
> * Allow data to be pulled directly from indexes
>
> Currently indexes do not have enough tuple tuple visibility
> information to allow data to be pulled from the index without
> also accessing the heap. One way to allow this is to set a bit
> to index tuples to indicate if a tuple is currently visible to
> all transactions when the first valid heap lookup happens. This
> bit would have to be cleared when a heap tuple is expired.
>
pass if "default_with_oids" is set to false. I took the approach of
explicitly adding WITH OIDS to the CREATE TABLEs where necessary, rather
than tweaking the default_with_oids GUC var.
(1) Keep a pin on the scan's current buffer and mark buffer. This
avoids the need to do a ReadBuffer() for each tuple produced by the
scan. Since ReadBuffer() is expensive, this is a significant win.
(2) Convert a ReleaseBuffer(); ReadBuffer() pair into
ReleaseAndReadBuffer(). Surely not a huge win, but it saves a lock
acquire/release...
(3) Remove a bunch of duplicated code in rtget.c; make rtnext() handle
both the "initial result" and "subsequent result" cases.
(4) Add support for index tuple killing
(5) Remove rtscancache(): it is dead code, for the same reason that
gistscancache() is dead code (an index scan ought not be invoked with
NoMovementScanDirection).
The end result is about a 10% improvement in rtree index scan perf,
according to contrib/rtree_gist/bench.
