Re: [HACKERS] What about LIMIT in SELECT ?
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] What about LIMIT in SELECT ? |
Дата | |
Msg-id | 199810141801.OAA29496@candle.pha.pa.us обсуждение исходный текст |
Ответ на | RE: [HACKERS] What about LIMIT in SELECT ? ("Taral" <taral@mail.utexas.edu>) |
Список | pgsql-hackers |
[Charset iso-8859-1 unsupported, filtering to ASCII...] > > 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) Not sure you can do that. The index points to heap tuples/tids, and though there are tids in the rows, you can't access them as tids in memory. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-hackers по дате отправления: