RE: [HACKERS] Solution for LIMIT cost estimation
| От | Hiroshi Inoue |
|---|---|
| Тема | RE: [HACKERS] Solution for LIMIT cost estimation |
| Дата | |
| Msg-id | 000401bf78d8$ba187fa0$2801007e@tpf.co.jp обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Solution for LIMIT cost estimation (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > Philip Warner <pjw@rhyme.com.au> writes: > >> A possible answer is to define OFFSET/LIMIT in DECLARE CURSOR as > >> being simply a hint to the optimizer about how much of the query > >> result will actually get fetched. > > > This seems a good approach until cursors are fixed. But is > there a plan to > > make cursors support LIMIT properly? Do you know why they > ignore the LIMIT > > clause? > > Should they obey LIMIT? MOVE/FETCH seems like a considerably more > flexible interface, so I'm not quite sure why anyone would want to > use LIMIT in a cursor. > You are right. What I want is to tell optimizer the hint whether all_rows(total throughput) is needed or first_rows(constant response time) is needed. Regards. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: