Re: [GENERAL] 7.4Beta

Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)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(at)Yahoo(dot)com #