Message-ID: <3F3D14A2.6090407@Yahoo.com>
Date: Fri, 15 Aug 2003 13:13:06 -0400
From: Jan Wieck <JanWieck@Yahoo.com>
Organization: Unorganized
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephan Szabo <sszabo@megazone.bigpanda.com>,
	Christopher Kings-Lynne <chriskl@familyhealth.com.au>,
	Bruce Momjian <pgman@candle.pha.pa.us>,
	Peter Childs <Blue.Dragon@blueyonder.co.uk>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [GENERAL] 7.4Beta
References: <20030814223830.O6635-100000@megazone.bigpanda.com>
	<12535.1060948630@sss.pgh.pa.us>
In-Reply-To: <12535.1060948630@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

> Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
>> select * from fk where not exists(select * from pk where pk.key=fk.key)
>>  and key is not null;
>> (doing seq scan/subplan doing index scan - which is probably close to the
>> current system)
> 
> Actually, even that would probably be noticeably better than the current
> system.  I haven't profiled it (someone should) but I suspect that
> executor startup/shutdown time is a huge hit.  Even though the trigger
> is caching a plan, it has to instantiate that plan for each referencing
> tuple --- and the executor is not designed for quick startup/shutdown.
> 
> (Of course, this would become less relevant if the triggers got
> rewritten to not go through SPI ...)

One of the reasons why we used SPI to generate the plans was the ease of
use. I'm not 100% sure, but I think the standard doesn't require the
referencing and referenced column(s) to be identical, only compatible.
So for example a text type foreign key can reference a varchar() and an 
int4 can reference int8. Not using SPI for that lookup does not reduce 
to a simple index- or seq-scan (depending on index availability on the 
foreign key attributes).

Even if the standard does require it, we did not for a couple releases 
and breaking that backward compatibility is IMHO not an option.

I'm thinking instead of a way to "cache" entire executors for this. Each 
SPI plan used during a transaction would need it's own executor, and I 
don't know offhand what type and how much resources an executor requires 
(I think it's only some memory that get's initialized and the VFD's 
opened). If I also remember correctly, the executor holds the pointer to 
the parameters in the execstate and the actual values stay just in the 
caller provided array. All that can change for a given plan between 
SPI_execp() calls is this parameter array and the maxtuple arg. If an 
executor is comparably cheap resource wise, SPI_execp() should be able 
to just manipulate the parameter array in the execstate (with 
propagation into the scankeys I fear) and then let it do a rescan. At 
transaction commit time we'd need to close all executors then, like we 
do with cursors.

Does that all make any sense to you?


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #