From: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, chris(at)bitmead(dot)com |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Solution for LIMIT cost estimation |
Date: | 2000-02-11 05:38:10 |
Message-ID: | 3.0.5.32.20000211163810.035e1aa0@mail.rhyme.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At 22:52 10/02/00 -0500, Tom Lane wrote:
>
>But having said that, I hear what you're saying and I think it's
>worth thinking about. Here are four possible alternative responses:
>
Another option is to do what Dec/Rdb does, and allow either optimizer hints
in a saved plan, or via modified SQL (less portable):
select * from foo limit 1 row optimize for fast first;
I also have a question: does the optimizer know about relevant indexes when
it is trying to return an ordered result set? If not, then 'fast first'
retrieval may be substantially improved by including such knowledge.
ie.
select * from foo order by f1,f2 limit 1 row;
should be trivial if there is an index on (f1,f2).
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2000-02-11 06:10:35 | Almost there on column aliases |
Previous Message | Chris Bitmead | 2000-02-11 04:57:20 | Re: [HACKERS] libpq |