On 2016-08-30 07:38:10 -0400, Tom Lane wrote: > Heikki Linnakangas <hlinn...@iki.fi> writes: > > While profiling some queries and looking at executor overhead, I > > realized that we're not making much use of TupleTableSlot's ability to > > hold a buffer pin. In a SeqScan, the buffer is held pinned by the > > underlying heap-scan anyway. Same with an IndexScan, and the SampleScan. > > I think this is probably wrong, or at least very dangerous to remove. > The reason for the feature is that the slot may continue to point at > the tuple after the scan has moved on.
FWIW, that's not safe to assume in upper layers *anyway*. If you want to do that, the slot has to be materialized, and that'd make a local copy. If you don't materialize tts_values/isnull can point into random old memory (common e.g. for projections and virtual tuples in general). Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
