hurray!
ANALYZING changed the plan
I was not expecting the plan to change because
the partition of 2006_02 is supposed to be
dormant. maybe the partition was never analyzed.
But still question remains, why the time taken was
in orders of magnitude higher in loaded condition.
tradein_clients=>
thanks for the hint,
now the peak hour is over and the same scan is taking 71 ms in place of 8 ms
and the total query time is also acceptable. But it is surprising that
the scan was
taking so long consistently at that point of time. I shall test again
under similar
circumstance tomorrow.
Is i
Both queries are using your uid index on each of the partitions not
generated_date, it's doing the generated_date with a filter on most of the
partitions.
This is except for on partition part_2006_02 in the second query where it uses
your generated date index - and that takes the 80 secs.
