Okay, that's helpful. I found the relevant code in /backend/tcop/postgres.c and it's as you say, process start vs query start ...
OK, so these numbers are OS-level page faults. Can you help me understand what a page fault on an update would mean? Is it that the disk page containing some or all of the row to be updated is not found in the OS cache? Lastly, any idea why I would see executor stats twice (or in one case this morning) three times in a row? Is it actually re-running the query? Here's one last oddness: the vast bulk of these problem queries occur when we're updating a session table, where our logic is: 1) Send the query as an INSERT 2) See if it fails 3) If so, resend as an UPDATE The initial INSERTs never show this kind of problem, only the subsequent UPDATES. Is there something in our pattern that somehow increases the possibility of a cache miss? The example of sequential reads on a non-interleaved hard drive comes to mind, but I can't imagine that that's useful except in some vague metaphorical way ... -- sgl > From: Tom Lane <[EMAIL PROTECTED]> > Date: Thu, 26 Aug 2004 10:51:21 -0400 > To: Steve Lane <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], Jamie Thomas <[EMAIL PROTECTED]> > Subject: Re: [ADMIN] Odd double queries continues > > Steve Lane <[EMAIL PROTECTED]> writes: >> I realize no one may have any insight in the whole problem, but can anyone >> at least tell me the significance of each of these numbers from the stats: >> 261/10 [691/281] page faults/reclaims, 0 [0] swaps > > It's just repeating what getrusage() told it. See the docs for your > operating system. > > It looks like the numbers inside the square brackets are totals since > process start, while the ones before are the delta since query start. > > regards, tom lane > ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
