[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] [GENERAL] Re : Solaris Performance - 64 bit puzzle
From:       Andrew Sullivan <andrew () libertyrms ! info>
Date:       2002-04-30 20:34:24
[Download RAW message or body]

On Tue, Apr 30, 2002 at 03:28:13PM -0400, Tom Lane wrote:
> Andrew Sullivan <andrew@libertyrms.info> writes:
> > ... In any case, I can't offer a definite
> > answer about the 64-bit qsort for now.
> 
> Do you need to profile it?  It seemed that the 32-bit behavior for
> many-equal-keys was so bad that it'd be easy to tell whether it's
> fixed, just by rough overall timing of a test case...

Yes, that's what I thought, too, so I figured I'd do that instead
(although I didn't think of it until after I sent the mail).  On the
other hand, now I'm like a dog with a bone, because I want to know
why in the world it doesn't work.  No wonder I never get anything
done.

Thanks to Travis Hoyt, who pointed out that I could at least test for
library problems with truss.  I did, and the interesting thing is
that it appears to be the profile writing that's causing the segfault
(it's during the write to gmon.out that the segfault occurs).  So my
earlier view was wrong.  But in any case, it looks like there really
is something broken about profiling with this configuration.

Since the original case was so bad, can anyone tell me roughly how
many equal keys were in the set, and how big the total set was?  That
way I'll be able to get something reasonably close, and I can use
wall-clock time or something to expose whether there's a problem for
64 bit libraries too.  

Thanks,
A

-- 
----
Andrew Sullivan                               87 Mowat Avenue 
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M6K 3E3
                                         +1 416 646 3304 x110


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
[prev in list] [next in list] [prev in thread] [next in thread]