row estimation off the mark when generate_series calls are involved - Mailing list pgsql-hackers

From Nikhil Sontakke
Subject row estimation off the mark when generate_series calls are involved
Date
Msg-id x2ta301bfd91004182334r2bb2d0eer61866f04a1d1fef8@mail.gmail.com
Whole thread Raw
Responses Re: row estimation off the mark when generate_series calls are involved  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
List pgsql-hackers
Another email which went into the wilderness when I sent it to pgsql-patches.

Regards,
Nikhils


---------- Forwarded message ----------
From: Nikhil Sontakke <nikhil.sontakke@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@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

Attachment

pgsql-hackers by date:

Previous
From: Nikhil Sontakke
Date:
Subject: CTAS not honoring NOT NULL, DEFAULT modifiers
Next
From: Simon Riggs
Date:
Subject: Re: [COMMITTERS] pgsql: Tune GetSnapshotData() during Hot Standby by avoiding loop