Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)

Tom Lane wrote:

> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > Tom Lane wrote:
> >> Yes, but why should the presence of "limit all" affect that?
> >> It's not apparent to me why the optimizer should treat this
> >> case differently from plain
> >> declare myc cursor for select * from t1;
>
> > Am I misunderstanding ?
> > Doesn't optimizer make the plan for the query
> > "select * for t1" which would use SeqScan
> > in most cases ?
>
> In a plain SELECT, yes. In a DECLARE CURSOR, it's currently set up
> to prefer indexscans anyway, LIMIT or no LIMIT (see lines 853 ff in
> src/backend/optimizer/plan/planner.c, current sources).

Probably you mean
if (parse->isPortal)
tuple_fraction = 0.10;

Seems 0.10 isn't sufficently small in pretty many cases.
In addtion,SeqScan isn't used even when we want it e.g.
in the case cursors are just used to avoid the exhaution
of memory.

> I think it
> makes sense to have that preference for DECLARE, and what I'm wondering
> is if we need an additional preference when the DECLARE contains a LIMIT
> clause --- and if so, what should that be?
>

I don't think we can specify appropriate LIMIT for cursors.
We could judge if an application needs an average response
time of total throuput.

Regards, Hiroshi Inoue