>
> On Jul 24, 2008, at 11:11 AM, Zdenek Kotala wrote:
>
>> I performed review and I prepared own patch which contains only probes
>> without any issue. I suggest commit this patch because the rest of
>> patch is independent and it can be committed next commit fest after
>> rework.
>>
>> I found following issues:
>>
>> 1) SLRU probes.
>>
>> I think it is good to have probes there but they needs polish. See my
>> comments
>> http://reviewdemo.postgresql.org/r/25/
>
> The slru's are quite useful and general enough to use easily. I used
> them to verify the metered checkpointing stuff:
>
> http://lethargy.org/~jesus/archives/112-Probing-for-Success.html
I agree that SLRU probes are useful but I'm worry about implementation. I think
that these probes need more work before commit. Currently there are several bugs
in placement and arguments (from my point of view).
>> 3) Executor probes
>>
>> I would like to see any use case for them/
>
> I added them with two thoughts (and knowing that they cost nothing).
> (1) you can trace them to assist in debugging an explain plan and to
> better understand the flow of the execution engine. This is not a
> compelling reason, but a reason none-the-less.
> (2) you can trace and existing long-running query for which you do not
> have the original plan (may have changed) and make an educated guess at
> the plan chosen at time of execution.
I'm not executor expert and (1) is useful for me :-). What I'm thinking about is
if we can mine more information from executor like number of tuples processed by
node number and so on. I think that it needs discussion.
>> 8) mark dirty and BM_HINT... flag
>>
>> I remove these because I don't see any use case for it. It would be
>> nice provide some dtrace script or describe basic ideas.
>
>
> Perhaps I misunderstood what mark dirty does, but here was my thinking:
>
> Because of the background writer, it is difficult to understand which
> postgres process (and thus query) induced disk writes. Marking a page
> as dirty is a good indication that a query will be causing I/O and you
> can measure calls to mark dirty per query as a telling metric.
>
> Perhaps I misunderstood, but I have a very serious problem that I can't
> reliably track write I/O to postgresql process ID as the bgwriter and
> the kernel are flushing those dirty blocks to disk while the process
> isn't running. In my (albeit naive) tests, the mark dirty gave me quite
> expected results for correlating query execution to disk I/O to be induced.
>
If I understand correctly you need to analyze number of writes per
query/session. It seems to me, that to use mark dirty is good way, but it
probably needs more probes. (Robert L. any idea?)
However what I suggested is commit probes without issue now and the rest will be
processed on the next commit fest after rework/discussion.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment