Re: PostgreSQL Caching - Mailing list pgsql-performance

From Tomeh, Husam
Subject Re: PostgreSQL Caching
Date
Msg-id CB0FB369FF86E248A884BCC002562BCB0227DA91@pisgsna01sxch01.ana.firstamdata.com
Whole thread Raw
In response to Re: PostgreSQL Caching  ("Adnan DURSUN" <a_dursun@hotmail.com>)
Responses Re: PostgreSQL Caching
List pgsql-performance
>>      * When any session updates the data that already in shared
buffer,
>>does Postgres synchronize the data both disk and shared buffers area
>> immediately ?

Not necessarily true. When a block is modified in the shared buffers,
the modified block is written to the Postgres WAL log. A periodic DB
checkpoint is performed to flush the modified blocks in the shared
buffers to the data files.

>>  * Does postgres cache SQL execution plan analyze results in memory
>> to use for other sessions ? For example ;
>>        When session A execute "SELECT * FROM tab WHERE col1 = val1
AND col2
>> = val2", does postgres save the parser/optimizer result in memory in
order
>>         to use by other session to prevent duplicate execution of
parser
>> and optimizer so therefore get time ?. Because an execution plan is
created
>> before..

Query plans are not stored in the shared buffers and therefore can not
be re-used by other sessions. They're only cached by the connection on a
session level.

Sincerely,

--
  Husam

-----Original Message-----
From: pgsql-performance-owner@postgresql.org
[mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Adnan
DURSUN
Sent: Tuesday, October 03, 2006 4:53 PM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] PostgreSQL Caching


        Thanks,

        I wonder these ;

        * When any session updates the data that allready in shared
buffer,
does Postgres sychronize the data both disk and shared buffers area
immediately ?
        * Does postgres cache SQL execution plan analyze results in
memory
to use for other sessions ? For example ;
        When session A execute "SELECT * FROM tab WHERE col1 = val1 AND
col2
= val2", does postgres save the parser/optimizer result in memory in
order
         to use by other session to prevent duplicate execution of
parser
and optimizer so therefore get time ?. Because an execution plan is
created
before..

Sincenerly

Adnan DURSUN

----- Original Message -----
From: "Tomeh, Husam" <htomeh@firstam.com>
To: "Adnan DURSUN" <a_dursun@hotmail.com>;
<pgsql-performance@postgresql.org>
Sent: Wednesday, October 04, 2006 1:11 AM
Subject: Re: [PERFORM] PostgreSQL Caching



Like many descent RDBMS, Postgresql server allocates its own shared
memory area where data is cached in. When receiving a query request,
Postgres engine checks first its shared memory buffers, if not found,
the engine performs disk I/Os to retrieve data from PostgreSQL data
files and place it in the shared buffer area before serving it back to
the client. Blocks in the shared buffers are shared by other sessions
and can therefore be possibly accessed by other sessions. Postgresql
shared buffers can be allocated by setting the postgresql.conf parameter
namely, shared_buffers.

Sincerely,

--
  Husam

-----Original Message-----
From: pgsql-performance-owner@postgresql.org
[mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Adnan
DURSUN
Sent: Tuesday, October 03, 2006 2:49 PM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] PostgreSQL Caching

        Hi,

    I wonder how PostgreSQL caches the SQL query results. For example ;

        * does postgres cache query result in memory that done by
session A
?
        * does session B use these results ?

Best Regards

Adnan DURSUN


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
**********************************************************************
This message contains confidential information intended only for the use
of
the addressee(s) named above and may contain information that is legally

privileged.  If you are not the addressee, or the person responsible for

delivering it to the addressee, you are hereby notified that reading,
disseminating, distributing or copying this message is strictly
prohibited.
If you have received this message by mistake, please immediately notify
us
by replying to the message and delete the original message immediately
thereafter.

Thank you.

                                   FADLD Tag
**********************************************************************


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo@postgresql.org so that your
       message can get through to the mailing list cleanly


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster


pgsql-performance by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Forcing the use of particular execution plans
Next
From: "Adnan DURSUN"
Date:
Subject: Re: PostgreSQL Caching