From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Performance problem partially identified |
Date: | 1999-05-28 18:06:13 |
Message-ID: | 21804.927914773@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I've been looking into Mergl's "update" performance problem. With
current sources, on a sequential-scan update of about 10,000 out of
1,000,000 records, I observe 33712 read() calls and 34107 write() calls.
The table occupies 33334 disk blocks, so the number of reads looks about
right -- but the number of writes is at least a factor of 3 higher than
it should be!
It looks to me like something is broken such that bufmgr.c *always*
thinks that a buffer is dirty (and needs written out) when it is
released.
Poking around for the cause, I find that heapgettup() calls
SetBufferCommitInfoNeedsSave() for every single tuple read from the
table:
7.14 42.15 1000055/1000055 heap_getnext [9]
[10] 18.8 7.14 42.15 1000055 heapgettup [10]
1.53 30.10 1000020/1000020 HeapTupleSatisfiesSnapshot [11]
1.68 3.27 1000055/1000055 RelationGetBufferWithBuffer [50]
4.31 0.00 2066832/4129472 LockBuffer [45]
0.25 0.56 33361/33698 ReleaseAndReadBuffer [76]
0.44 0.00 1000000/1000000 SetBufferCommitInfoNeedsSave [92]
0.01 0.00 33371/33371 nextpage [240]
0.00 0.00 10/2033992 ReleaseBuffer [46]
0.00 0.00 45/201 HeapTupleSatisfiesNow [647]
0.00 0.00 5/9 nocachegetattr [730]
This could only be from the call to SetBufferCommitInfoNeedsSave in
the HeapTupleSatisfies macro. If I'm reading the code correctly,
that means that HeapTupleSatisfiesSnapshot() always changes the
t_infomask field of the tuple.
I don't understand this code well enough to fix it, but I assert that
it's broken. Most of these tuples are *not* being modified, and there
is no reason to have to rewrite the buffer.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-05-28 18:33:39 | Re: [HACKERS] Ye olde "relation doesn't quite exist" problem |
Previous Message | Bruce Momjian | 1999-05-28 17:02:57 | PostgreSQL article |