RE: [HACKERS] Solution for LIMIT cost estimation

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

In response to

Browse pgsql-hackers by date

  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