Re: [HACKERS] TIME QUALIFICATION

From: jwieck(at)debis(dot)com (Jan Wieck)
To: vadim(at)krs(dot)ru (Vadim Mikheev)
Cc: jwieck(at)debis(dot)com, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] TIME QUALIFICATION
Date: 1999-02-10 09:26:34
Message-ID: m10AVuk-000EBRC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vadim wrote:

> Ok. If you feel that QueryIds is easier way to go then do it.
> In any case some preprocessing of plan tree just before execution
> will be required.
> BTW, why not use CommandIds ?

CommandId is the order in which plans get executed and
snapshots created. But it isn't the order in which the plans
got created. There could easily hundreds of CommandId's been
created until a deferred query executes. Some of it's RTE's
must get the QuerySnapshot and scanCommandId of an earlier
executed plan. But at the time it will be saved for deferred
execution, I cannot foresee the CommandId it's parents will
get.

And the case of cascaded rules? Initial query fires rule
action 1 which in turn fires rule action 2. Now initial query
executes and fires trigger which executes it's own commands.
Thus, the parent of action 2 will not get the second
CommandId of the transaction.

A plan get's associated with a CommandId at the time it's
execution starts. So it's useless to tell the relationship
between RTE's.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas IZ5 1999-02-10 10:07:26 AW: [HACKERS] NEXTSTEP porting problems
Previous Message Tatsuo Ishii 1999-02-10 08:59:01 Re: [HACKERS] cannot cast bpchar and varchar