From: Jan Wieck <JanWieck@Yahoo.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephan Szabo <sszabo@megazone.bigpanda.com>
Cc: Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Peter Childs <Blue.Dragon@blueyonder.co.uk>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [GENERAL] 7.4Beta
Date: Fri, 15 Aug 2003 13:13:06 -0400
Message-ID: <3F3D14A2.6090407@Yahoo.com> (raw)
In-Reply-To: <12535.1060948630@sss.pgh.pa.us>
References: <20030814223830.O6635-100000@megazone.bigpanda.com>
<12535.1060948630@sss.pgh.pa.us>
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 #
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: JanWieck@Yahoo.com, tgl@sss.pgh.pa.us, sszabo@megazone.bigpanda.com, chriskl@familyhealth.com.au, pgman@candle.pha.pa.us, Blue.Dragon@blueyonder.co.uk
Subject: Re: [GENERAL] 7.4Beta
In-Reply-To: <3F3D14A2.6090407@Yahoo.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox