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
|
Список | 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 по дате отправления: