Robert Haas <robertmh...@gmail.com> writes:
> Not really. We have detected a small performance regression when both
> heap and index fit in shared_buffers and an index-only scan is used.
> I have a couple of ideas for improving this. One is to store a
> virtual tuple into the slot instead of building a regular tuple, but
> what do we do about tuples with OIDs?
Yeah, I was just looking at that. I think it's going to be a clear win
to use a virtual tuple slot instead of constructing and deconstructing
a HeapTuple. The obvious solution is to decree that you can't use an
index-only scan if the query requires fetching OID (or any other system
column). This would be slightly annoying for catalog fetches but I'm
not sure I believe that catalog queries are that important a use-case.
I was also toying with the notion of pushing the slot fill-in into the
AM, so that the AM API is to return a filled TupleSlot not an
IndexTuple. This would not save any cycles AFAICT --- at least in
btree, we still have to make a palloc'd copy of the IndexTuple so that
we can release lock on the index page. The point of it would be to
avoid the assumption that the index's internal storage has exactly the
format of IndexTuple. Don't know whether we'd ever have any actual use
for that flexibility, but it seems like it wouldn't cost much to
preserve the option.
> Another is to avoid locking the
> index buffer multiple times - right now it locks the index buffer to
> get the TID, and then relocks it to extract the index tuple (after
> checking that nothing disturbing has happened meanwhile). It seems
> likely that with some refactoring we could get this down to a single
> lock/unlock cycle, but I haven't figured out exactly where the TID
> gets copied out.
Yeah, maybe, but let's get the patch committed before we start looking
for second-order optimizations.
> With regard to the AM API, the basic idea is we're just adding a
> Boolean to say whether the AM is capable of returning index tuples.
> If it's not, then we don't ever try an index-only scan. If it is,
> then we'll set the want_index_tuple flag if an index-only scan is
> possible. This requests that the AM attempt to return the tuple; but
> the AM is also allowed to fail and not return the tuple whenever it
> wants.
It was the "allowed to fail" bit that I was annoyed to discover only by
reading some well-buried code.
> Incidentally, if you happen to feel the urge to beat this around and
> send it back rather than posting a list of requested changes, feel
> free.
You can count on that ;-). I've already found a lot of things I didn't
care for.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
