On 6 October 2011 21:11, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
+1 Been testing this today with a few regression tests and haven't seen anything noticeably broken. Does what it says on the tin. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
