Re: PG index architecture

From: Andy Colson <andy(at)squeakycode(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: PG index architecture
Date: 2014-07-15 21:54:00
Message-ID: 53C5A2F8.9060106@squeakycode.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John R Pierce 2014-07-15 22:02:54 Re: PG index architecture
Previous Message John R Pierce 2014-07-15 20:54:17 Re: PG index architecture