RE: [HACKERS] What about LIMIT in SELECT ?
От | Taral |
---|---|
Тема | RE: [HACKERS] What about LIMIT in SELECT ? |
Дата | |
Msg-id | 000001bdf79b$e75d87e0$3b291f0a@taral обсуждение исходный текст |
Ответ на | Re: [HACKERS] What about LIMIT in SELECT ? (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] What about LIMIT in SELECT ?
|
Список | 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
В списке pgsql-hackers по дате отправления: