Re: PG index architecture
От | Andy Colson |
---|---|
Тема | Re: PG index architecture |
Дата | |
Msg-id | 53C5A2F8.9060106@squeakycode.net обсуждение исходный текст |
Ответ на | Re: PG index architecture (John R Pierce <pierce@hogranch.com>) |
Ответы |
Re: PG index architecture
|
Список | pgsql-general |
On 7/15/2014 3:54 PM, John R Pierce wrote: > On 7/15/2014 1:26 PM, Andy Colson wrote: >> As I understand indexes, they are a key value pair, that contain a >> value and a position. You lookup the value then use the position to >> seek into the database to load the record. > > indexes are stored as a B-tree. each terminal node has a block number > for the target record. > >> >> Do we, or could we, load all the the matching index records, then sort >> them by position? (maybe not all, maybe large batches) >> > > b-trees are inherently ordered. data records, however are not. > > >> When loading from the database, if access was slightly more sequential >> (vs very random), would it increase performance? >> >> Said another way: >> >> I think of table scanning as sequential, and fast. That would be >> loading db record 1,2,3, etc. > > database tables are unordered sets, there is no record 1,2,3. > >> >> Would it be faster to load db records "mostly sequential": 1,3,4,7,10 >> compared to randomly: 7,3,10,1,4 > > its unclear to me what you mean here. > > Ah, yea, sorry, I don't really mean record #1, I mean hard drive seek to address 1. (where address came from the index lookup) Know what I mean? -Andy
В списке pgsql-general по дате отправления: