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 по дате отправления: