Re: [HACKERS] Solution for LIMIT cost estimation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: chris(at)bitmead(dot)com
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Date: 2000-02-11 14:59:59
Message-ID: 19423.950281199@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> writes:
> For my own curiousity, how does the presence of limit affect a plan
> anyway?

At the moment, it doesn't. But it should. To take an extreme example:

SELECT * FROM table WHERE x > 100 ORDER BY x LIMIT 1;

to get the tuple with lowest x > 100. Assuming that there is an index
on x, the right way to implement this is with an indexscan, because a
single probe into the index will pull out the tuple you want. But right
now the optimizer will choose a plan as if the LIMIT weren't there,
ie on the basis of estimated total cost to retrieve the whole ordered
result set. On that basis it might well choose sequential scan + sort,
so you'd have to wait around for a sort to complete before you get your
answer.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-02-11 15:07:04 Re: [HACKERS] Solution for LIMIT cost estimation
Previous Message Karel Zak - Zakkr 2000-02-11 10:34:52 Re: [INTERFACES] The persistance of C functions