Re: gprof SELECT COUNT(*) results

Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> I can see your computer is really slow, so my theory is that since it is
> easy to hold a running-slowly horse than a fast one, so my spinlock on a
> 2.4G modern machine should takes relatively longer time to get effective.
> Just kidding.

Is that "modern machine" a Xeon by any chance? We know that Xeons have
fairly awful concurrent performance, and the long latency for bus lock
instructions may well be the reason why. FWIW, the numbers I showed
last night were for an HPPA machine, which I used just because I chanced
to have CVS tip already built for profiling on it. I've since
reproduced the test on a spiffy new dual Xeon that Red Hat just bought
me :-) ... and I get similar numbers to yours. It'd be interesting to
see the results from an SMP Opteron, if anyone's got one handy.

>> The only other objection I can think of is that if there are any broken
>> tuples on a page, this approach would likely make it impossible to fetch
>> any of the non-broken ones :-(

> What do you mean by "broken tuple"? An data corrupted tuple?

The specific case that's worrying me is a tuple with a corrupted xmin,
such that tqual.c fails with a "can't access transaction status"
message.

> So you mean
> if scan operator find a broken tuple on a page, then it will abort the
> operation without returning any other good tuples? I think this is
> acceptable.

I think it would be totally unacceptable if it meant that there was no
way at all to look at the other data on the same page with a corrupt
tuple. Seqscans with "LIMIT n" have been the traditional tool for
getting as much info as you could out of a corrupted page. However,
it now occurs to me that you could still cherry-pick non-corrupt tuples
with TID-scan queries, so this objection shouldn't be considered fatal.

regards, tom lane