Re: PG index architecture - Mailing list pgsql-general

From Andy Colson
Subject Re: PG index architecture
Date
Msg-id 53C5A2F8.9060106@squeakycode.net
Whole thread Raw
In response to Re: PG index architecture  (John R Pierce <pierce@hogranch.com>)
Responses Re: PG index architecture  (John R Pierce <pierce@hogranch.com>)
List 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 by date:

Previous
From: John R Pierce
Date:
Subject: Re: PG index architecture
Next
From: John R Pierce
Date:
Subject: Re: PG index architecture