Re: Odd double queries continues

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 <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Date: Thu, 26 Aug 2004 10:51:21 -0400
> To: Steve Lane <slane(at)soliantconsulting(dot)com>
> Cc: pgsql-admin(at)postgresql(dot)org, Jamie Thomas <jthomas(at)soliantconsulting(dot)com>
> Subject: Re: [ADMIN] Odd double queries continues
>
> Steve Lane <slane(at)soliantconsulting(dot)com> 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
>