Re: [Postgres-xc-developers] Choosing nodes at the time of execution

[Nikhil S. <ni...@st...>]

>> > There is no way for the second session to know that there are prepared
>> > statements out there, so there is no stopping it from changing the
>> > preferred
>> > nodes. At the same time, I do not see any need to do so. Preferred node
>> > should be a dynamic non-blocking setting, very handy to tackle the
>> > network
>> > dynamics if needed.
>> >
>>
>> In this case the plan cache should be invalidated and re-built afresh.
>> The case should be similar to when the involved relations in a plan
>> undergo a change AFAICS.
>>
>
> When we can take care of this stuff (and without much change in the code),
> without plan cache invalidation, why to go the route of cache invalidation?
> Plan cache invalidation is a heavy operation in itself and its consequences
> cause performance degradation. Because of plan invalidation all those plans
> which are really not affected by this change, would be hit too.
>

You make this node ddl stuff sound like a routine activity. It's going
to be once in a while, right?

Regards,
Nikhils
-- 
StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Service