Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)
В списке pgsql-committers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c) |
| Дата | |
| Msg-id | 22987.972604192@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c) (Tom Lane <tgl@postgresql.org>) |
| Список | pgsql-committers |
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
>> Re-implement LIMIT/OFFSET as a plan node type, instead of a hack in
>> ExecutorRun. This allows LIMIT to work in a view. Also, LIMIT in a
>> cursor declaration will behave in a reasonable fashion,
> Does "reasonable" mean that LIMIT is treated as optimizer's
> hint but doesn't restrict total FETCH counts ?
No, it means that a LIMIT in a cursor means what it says: the cursor
will show that many rows and no more. FETCH lets you move around in
the cursor, but not override the limit. I decided that the other
behavior was just too darn weird... if you want to argue about that,
let's take it up on pghackers not committers.
Yes, the optimizer does pay attention to the limit.
regards, tom lane
В списке pgsql-committers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера