On Sat, Nov 12, 2016 at 10:28 AM, Andres Freund <and...@anarazel.de> wrote: > 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).
So, I think you are arguing in favor of proceeding with this patch? -- Robert Haas EnterpriseDB: 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
