Dear tom lane and hackers, I am sorry, I should have explained the reason.
Actually, I'm not modifying the backend source code. Since I am not a native speaker, I am not good at writing in English. I'm just trying to make my own pgsql code for my research purpose. Later, if my research turns out successful, then I can contribute in enhancing pgsql at that time by concretely implementing it. I'm researching on DBMS I/O performance issues regarding flash memory and flash-SSDs. Flash-memory has asynchronous read/write latency, and flash-SSDs as well. Therefore, reducing random-writes to flash based storage is quite a issue. What I am trying to do now is to examine the real dirty portion of buffer pages to be flushed like the following. page 1 ------------- | | dportion1 (real dirty portion 1) ranges between 20 ~ 80 | dportion1 | | | dportion2 (real dirty portion 2) ranges between 8190 ~ 8192 | | | dportion2 | ------------- Since there are many different kinds of page-updates such as updates to local buffer, temp relation, indexes, toasted attributes, and so forth. It would be a big burden to me if I inspect all that codes. Therefore, I decided to make a start point as inspecting only updates to the ordinary tables. I added a log array field to BufferDesc struct, and added logs to the designated bufferDesc of the updated buffer when it comes to ordinary table updates (The logs specifies the real dirty portion ranges of the buffer). So far, I covered (at least I thought I covered ..) several functions such as heap_udpate, heap_insert, heap_delete, heap_inplace_update, , heap_lock_tuple, heap_page_prune, heap_page_prune_execute, heap_lock_tuple, pageAddItem, pageRepairFragmenation, putRelationTuple. Until now I didn't care about vacuum-related function since I turned off the autovacuum option in the conf file. I think it's too early to tell how my idea is going to work. When I am ready to confidently say that my idea can enhance the pgsql's performance a little bit at less expense of losing other features, I will submit a proposal. It's, for sure, not easy to grasp how the backend works, though. Several articles and wiki pages helped me a lot, and especially well-annotated codes was the most helpful. What I have been going through helped me a lot to understand the internal of DBMSs, and actually it was fun to read the real working codes of a DBMS. In the aspect that this remarkable open-source DBMS codes are so well maintained and continuously enhanced by this community that many people including me can study and participate in, I really thank you and hackers. About the question, I think I am confused a little. I don't know why, but still the debug routine of my code says that the log inserted in heap_update belongs to a primary index relation. I will figure it out. - Best Regards Hongchan Roh - -----Original Message----- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Monday, October 26, 2009 12:07 AM To: 노홍찬 Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] a question about relkind of RelationData handed over to heap_update function =?ks_c_5601-1987?B?s+vIq8L5?= <falls...@cs.yonsei.ac.kr> writes: > I found that the relkind fields of all RelationData which is handed over to > heap_update are all the same as ‘r’. Well, yeah: heap_update is applied to heaps (ordinary tables). Not indexes. The indexes are generally updated in a separate operation afterwards. > I want to distinguish normal relation (actual table) from primary index > relation (primary indexes of some tables). Perhaps you should take about three steps back and explain what it is you want to do, because heap_update is probably not the right place to be doing it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
