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: