Re: A sniffer for the buffer

From: Jonas J <autoramajj(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A sniffer for the buffer
Date: 2009-12-08 14:49:28
Message-ID: 68962a630912080649o9151cc9kbcbae32faee479e8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for the answers.
I will change it for PostgreSQL 8.4 and try to use DBT-2.

But, I'm not quite sure if DTrace will give me the workload that I want.
Since, i want to trace the Workload that is above the Buffer Layer. With
workload I mean two fields (operation: read/write and Block Number). Then
all blocks that PostgreSQL request to the buffer layer I will capture.
Do DTrace can give my this information?

Thanks in advance,
Jonas Jeske

2009/12/8 Greg Smith <greg(at)2ndquadrant(dot)com>

> Jonas J wrote:
>
>> I took a look in the code again and made some changes. For the readBuffer
>> im doing now:
>> ReadBuffer(Relation reln, BlockNumber blockNum)
>> fprintf(fp,"r%u\n",(unsigned int) blockNum); //as defined in header,
>> typedef uint32 BlockNumber;
>> and from the write pages:
>> write_buffer(Buffer buffer, bool unpin){
>> fprintf(fp,"w%d\n",BufferGetBlockNumber(buffer)); //get the blockNumber of
>> this buffer
>>
> It's better to keep this discussion going on the list so you can get
> alternate suggestions besides mine. The above is better. You're still
> missing the relation number, which you're really going to want eventually.
> And I think you're still vulnerable to printing the information out before
> the block is locked properly in the write_buffer case.
>
>
> So, I had never used DTrace, where can I find some good paper to start
>> studying it ?? Also, do it work with linux, or only solaris ??
>>
> You can get it to work on Linux for PostgreSQL use if you use systemtap;
> there's some people who've posted suggestions about that around.
>
>> P.S.: I'm using PostgreSQL 8.1.4 to run with TPCC-UVA benchmarks tests...
>>
> Ah. PostgreSQL 8.1 is significantly slower than the current versions, and
> you're not going to get as much help with issues related to the source code
> as if you're using a newer one. For example, I don't know the 8.1 buffer
> implementation code nearly as well because I didn't really start tinkering
> with it until 8.2, so some of the things you're asking about I don't have
> easy access or recollection of. Also, the DTrace stuff is only really going
> to be helpful if you're starting with 8.4.
>
> There may be some work to get TPCC-UVA working with 8.4 though,
> particularly due to some changes made in 8.3 related to casting data to
> other types. There is a TPC-C implementation that's used pretty often by
> developers here named dbt-2: http://wiki.postgresql.org/wiki/DBT-2 that
> will work with a newer version.
>
>
> --
> Greg Smith 2ndQuadrant Baltimore, MD
> PostgreSQL Training, Services and Support
> greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ross J. Reedstrom 2009-12-08 14:54:49 Re: [HACKERS] New PostgreSQL Committers
Previous Message Heikki Linnakangas 2009-12-08 14:23:16 Streaming replication and non-blocking I/O