Skip site navigation (1) Skip section navigation (2)

Re: Executor question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Executor question
Date: 2008-07-26 17:20:48
Message-ID: 24095.1217092848@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> However, tracing through the code suggests that neither ExecInsert not
> intorel_receive will modify a passed raw tuple - ExecInsert calls
> ExecMaterializeSlot before heap_insert, and intorel_receive calls
> ExecCopySlotTuple before heap_insert.

> So is the ExecMayReturnRawTuples and corresponding ExecFilterJunk needed
> at all? Or am I missing something?

You might be right.  The forced-projection logic dates from a time
when ExecInsert actually would scribble right on the tuple in the
slot it was handed (look at 8.0 or so), but with the addition of
"virtual" tuple table slots the ExecMaterializeSlot call was needed,
and so we might not need the forced projection anymore.

It'd be cool if we could get rid of ExecMayReturnRawTuples
altogether ... I'll take a look.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-07-26 17:43:06
Subject: Re: pg_dump additional options for performance
Previous:From: Joshua D. DrakeDate: 2008-07-26 16:59:10
Subject: Re: pg_dump(all) library

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group