Prev: [HACKERS] CTAS not honoring NOT NULL, DEFAULT modifiers
Next: [HACKERS] Move tablespace
From: Nikhil Sontakke on 19 Apr 2010 02:34
Another email which went into the wilderness when I sent it to pgsql-patches.

Regards,
Nikhils


---------- Forwarded message ----------
From: Nikhil Sontakke <nikhil.sontakke(a)enterprisedb.com>
Date: Fri, Apr 16, 2010 at 6:50 PM
Subject: row estimation off the mark when generate_series calls are involved
To: pgsql-patches(a)postgresql.org


Hi,

I observed the following behavior on PG head:

postgres=# create table x(x int);
CREATE TABLE
postgres=# explain verbose insert into public.x values (generate_series(1,10));
------------------------------------------------
 Insert  (cost=0.00..0.01 rows=1 width=0)

postgres=# explain verbose insert into public.x values
(generate_series(1,1000));
------------------------------------------------
 Insert  (cost=0.00..0.01 rows=1 width=0)

So even though generate_series has a prorows value of 1000 (why did we
pick this value, just a guesstimate I guess?), its effects are not
shown in the plan at all. I think the place where we set the
targetlist of the result_plan to sub_tlist, immediately after that we
should update the plan_rows estimate by walking this latest
targetlist. I did that and now we seem to get proper row estimates.

Comments?

Regards,
Nikhils
--
http://www.enterprisedb.com



--
http://www.enterprisedb.com
 | 
Pages: 1
Prev: [HACKERS] CTAS not honoring NOT NULL, DEFAULT modifiers
Next: [HACKERS] Move tablespace