Thanks.
Time is little but visible affected for big chierarhies.
Let me do an other question.
I have again a Root table and a hierarchie of tables, all created with the
inherits relationship like:
create table father(att0 int4);
create table child1() inherits(father);
create table child2() inherits(father);
create table child11() inherits(child1);
create table child12() inherits(child1);
create table child21() inherits(child2);
create table child22() inherits(child2);
First i insert 1000 tuples into father table, and then i delete them and i
insert them into child22
I expekt explain analyze to give the same response time at both cases. But
i found that time increases as where as the level, where data are located,
increases.
Can anybody explain me the reason?
On Sun, 22 Aug 2004, Tom Lane wrote:
> Ioannis Theoharis <theohari@ics.forth.gr> writes:
> > I expekt to find the same plans because in both cases there is a union to
> > be done, but i see that in second case there is an additional call to a
> > routine. I meen the 'Subquery Scan "*SELECT* X"'
>
> The subquery scan step is in there because in a UNION construct, there
> may be a need to do transformations on the data before it can be
> unioned. For instance you are allowed to UNION an int4 and an int8
> column, in which case the int4 values have to be promoted to int8 after
> they come out of the subplan.
>
> In the particular case you are showing, the subquery scan steps aren't
> really doing anything, but AFAIR the planner does not bother to optimize
> them out. I'd be pretty surprised if they chew up any meaningful amount
> of runtime.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
>