Re: Function call hierarchy/path since getting the buffer until access its data - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Function call hierarchy/path since getting the buffer until access its data
Date
Msg-id CA+Tgmobc96kV4=5fnuwzewx1d5ZB=XOA+3W-_=mjDxAepUFssQ@mail.gmail.com
Whole thread Raw
In response to Function call hierarchy/path since getting the buffer until access its data  (Waldecir Faria <fighter2929@hotmail.com>)
Responses Re: Function call hierarchy/path since getting the buffer until access its data
List pgsql-hackers
On Mon, May 28, 2012 at 8:15 AM, Waldecir Faria <fighter2929@hotmail.com> wrote:
> Good morning, I am doing a study about buffer management to improve the
> performance of one program that does heavy I/O operations. After looking and
> reading from different softwares' source codes/texts one friend suggested me
> to take a look at the PostgreSQL code. I already took a look at the
> PostgreSQL buffer management modules ( freelist.c and cia ) but now I am a
> bit confused how the buffer read/write works, I tried to see how PostgreSQL
> does to get, for example, a char array from one buffer. Looking at rawpage.c
> I think that I found a good example using the following function calls
> sequence starting at function get_raw_page_internal():
>
> StrategyGetBuffer->BufferAlloc->ReadBuffer_Common
> ->ReadBufferExtended->BufferGetPage-> memcpy page to buf

BufferGetPage() doesn't copy anything; it just takes the buffer number
and returns a pointer to the address of that buffer in memory.  More
generally, that whole chain of function calls has to do with how a
page ends up inside PostgreSQL's buffer cache, not with how anything
on the page is actually decoded.  Each buffer contains zero or more
tuples; each tuple contains multiple attributes.  So after you get the
buffer you have to iterate over the tuples and then decode each tuple
to get the values that you want.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Florian Pflug
Date:
Subject: Re: [RFC] Interface of Row Level Security
Next
From: Robert Haas
Date:
Subject: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)