Re: a question about relkind of RelationData handed over to heap_update function

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: a question about relkind of RelationData handed over to heap_update function
Дата
Msg-id 407d949e0910261022w25a514c7hc186ce7fe10d7e28@mail.gmail.com
обсуждение исходный текст
Ответ на Re: a question about relkind of RelationData handed over to heap_update function  (노홍찬 <fallsmal@cs.yonsei.ac.kr>)
Ответы Re: a question about relkind of RelationData handed over to heap_update function  (노홍찬 <fallsmal@cs.yonsei.ac.kr>)
Список pgsql-hackers
On Sun, Oct 25, 2009 at 9:37 AM, 노홍찬 <fallsmal@cs.yonsei.ac.kr> wrote:
> 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).
>

I would think you would want to modify MarkBufferDirty to take a start
and end point and store that in your log. Then modify every existing
MarkBufferDirty operation that you can to specify the range that the
subsequent operation is going to modify. You're going to run into
problems where you have code which looks like:
- mark buffer dirty- do some work which modifies a predictable portion- if (some rare condition)   - do some more work
whichmodifies other parts of the buffer 

The "some more work" may be some function call which doesn't usually
do much either.

So you may end up having to restructure a lot of code so that every
function is responsible for marking the buffer range dirty itself
instead of assuming it's already been marked.


--
greg


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Cédric Villemain
Дата:
Сообщение: Re: per table random-page-cost?
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: Scaling up deferred unique checks and the after trigger queue