Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c) - Mailing list pgsql-committers

From Hiroshi Inoue
Subject Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
Date
Msg-id 39F90D62.F1BF5969@tpf.co.jp
Whole thread Raw
In response to pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)  (Tom Lane <tgl@postgresql.org>)
Responses Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers

Tom Lane wrote:

> Hiroshi Inoue <Inoue@tpf.co.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



pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
Next
From: Bruce Momjian - CVS
Date:
Subject: pgsql/doc/src/sgml (jdbc.sgml)