On Tue, Feb 2, 2010 at 7:14 PM, Tom Lane wrote:
> "Davor J." writes:
> > Now, if one takes a subquery for "1", the optimizer evaluates it first
> > (let's say to "1"), but then searches for it (sequentially) in every
> > partition, which, for large partitions, can be very time-consuming and
> go
Tom Lane writes:
> "Davor J." writes:
>> Now, if one takes a subquery for "1", the optimizer evaluates it first
>> (let's say to "1"), but then searches for it (sequentially) in every
>> partition, which, for large partitions, can be very time-consuming and goes
>> beyond the point of partitio
"Davor J." writes:
> Now, if one takes a subquery for "1", the optimizer evaluates it first
> (let's say to "1"), but then searches for it (sequentially) in every
> partition, which, for large partitions, can be very time-consuming and goes
> beyond the point of partitioning.
No, the optimizer
Let's say you have one partitioned table, "tbl_p", partitioned according to
the PK "p_pk". I have made something similar with triggers, basing myself on
the manual for making partitioned tables.
According to the manual, optimizer searches the CHECKs of the partitions to
determine which table(s)
