From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Philip Warner" <pjw(at)rhyme(dot)com(dot)au> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | RE: [HACKERS] Solution for LIMIT cost estimation |
Date: | 2000-02-16 23:51:21 |
Message-ID: | 000401bf78d8$ba187fa0$2801007e@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> Philip Warner <pjw(at)rhyme(dot)com(dot)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(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2000-02-17 00:42:24 | create database doesn't work well in MULTIBYTE mode |
Previous Message | Bruce Momjian | 2000-02-16 23:36:15 | psql password prompt |