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

Предыдущее
От: Larry Rosenman
Дата:
Сообщение: Re: pgsql/src/makefiles (Makefile.freebsd Makefile.hpux Makefile.irix5 Makefile.linux Makefile.netbsd Makefile.openbsd Makefile.osf Makefile.solaris Makefile.unixware)
Следующее
От: Hiroshi Inoue
Дата:
Сообщение: Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)