Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
| От | Tom Lane |
|---|---|
| Тема | Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c) |
| Дата | |
| Msg-id | 28051.972621258@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c) (Tom Lane <tgl@postgresql.org>) |
| Ответы |
Re: pgsql/src/backend/nodes (copyfuncs.c
outfuncs.c print.c)
|
| Список | pgsql-committers |
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). 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?
regards, tom lane
В списке pgsql-committers по дате отправления: