Re: [HACKERS] TIME QUALIFICATION

Поиск
Список
Период
Сортировка
От jwieck@debis.com (Jan Wieck)
Тема Re: [HACKERS] TIME QUALIFICATION
Дата
Msg-id m10AVuk-000EBRC@orion.SAPserv.Hamburg.dsh.de
обсуждение исходный текст
Ответ на Re: [HACKERS] TIME QUALIFICATION  (Vadim Mikheev <vadim@krs.ru>)
Ответы Re: [HACKERS] TIME QUALIFICATION  (jwieck@debis.com (Jan Wieck))
Список 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@debis.com (Jan Wieck) #

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: [HACKERS] cannot cast bpchar and varchar
Следующее
От: Zeugswetter Andreas IZ5
Дата:
Сообщение: AW: [HACKERS] NEXTSTEP porting problems