From: | "Taral" <taral(at)mail(dot)utexas(dot)edu> |
---|---|
To: | "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us>, "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | <jwieck(at)debis(dot)com>, <eric(at)linux-hw(dot)com>, <jeff(at)remapcorp(dot)com>, <hackers(at)postgreSQL(dot)org> |
Subject: | RE: [HACKERS] What about LIMIT in SELECT ? |
Date: | 1998-10-14 17:56:00 |
Message-ID: | 000001bdf79b$e75d87e0$3b291f0a@taral |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
> Thomas is correct on this. Vadim has run some tests, and with our
> optimized psort() code, the in-memory sort is often faster than using
> the index to get the tuple, because you are jumping all over the drive.
> I don't remember, but obviously there is a break-even point where
> getting X rows using the index on a table of Y rows is faster , but
> getting X+1 rows on a table of Y rows is faster getting all the rows
> sequentailly, and doing the sort.
>
> You would have to pick only certain queries(no joins, index matches
> ORDER BY), take the number of rows requested, and the number of rows
> selected, and figure out if it is faster to use the index, or a
> sequential scan and do the ORDER BY yourself.
Since a sort loads the data into memory anyway, how about speeding up the
sort by using the index? Or does that take up too much memory? (approx 40%
more than the data alone, I think)
TAra
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 1998-10-14 17:57:27 | Re: [HACKERS] What about LIMIT in SELECT ? |
Previous Message | Terry Mackintosh | 1998-10-14 17:45:40 | Re: [HACKERS] What about LIMIT in SELECT ? |
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 1998-10-14 17:57:27 | Re: [HACKERS] What about LIMIT in SELECT ? |
Previous Message | Terry Mackintosh | 1998-10-14 17:45:40 | Re: [HACKERS] What about LIMIT in SELECT ? |