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 <[EMAIL PROTECTED]> 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 > > ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html