On 7/15/2014 2:54 PM, Andy Colson wrote:
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)
of course, its a file+offset, so there's at least 1-2 more levels of
indirection before you get to physical addresses on t
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.
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
fo
Andy Colson writes:
> 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.
> Do we, or could we, load all the the matching index records, then sort
> them by positi
> -Original Message-
> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
> ow...@postgresql.org] On Behalf Of Andy Colson
> Sent: Tuesday, July 15, 2014 4:27 PM
> To: pgsql
> Subject: [GENERAL] PG index architecture
>
> I was thinking about index
I was thinking about indexes, and am kinda curious about sequential access.
I know nothing of PG guts, so this might even be a dumb question.
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 da
