On 12/16/10 8:11 AM, Dmitry Lenev wrote:
> Hello Davi!
> * Davi Arnaut<davi.arnaut@stripped> [10/12/16 12:26]:
>> On 12/16/10 5:21 AM, Dmitry Lenev wrote:
>>> Hello Davi!
>>> * Davi Arnaut<davi.arnaut@stripped> [10/12/14 02:35]:
>>>> # At a local mysql-5.1-bugteam repository of davi
>>>> 3520 Davi Arnaut 2010-12-13
>>>> Bug#42054: SELECT CURDATE() is returning bad value
>>>> Since this logic was being used due to ancient performance
>>>> the solution is to simply rely on time(), which nowadays is just
>>>> wrapper around the somewhat fast gettimeofday function.
>>> Could you please elaborate when has this change occurred and what
>>> has changed?
>> I didn't look up the history. What I had found was this:
>> Where time() is mapped to a gettimeofday.
>> But now I see that there is another time implementation:
>> that calls the time system call.
>> We need to find out what is the difference between libbc and libc.
> http://www.mail-archive.com/opensolaris-code@ style="color:#666">stripped/msg00781.html
> Says that 'libbc is the "backward compatibility" library which is
> present only on SPARC; it's a C library in Solaris native format but
> implementing the SunOS 4.x runtime'.
> So AFAIU it is not the thing which is used by default.
>>> Looking at OpenSolaris sources (yes, I know it is discontinued) I still
>>> can see that time() uses systrap whereas gethrtime() uses something which
>>> is called *fast*" systrap.
>> gettimeofday also uses a "fast" systrap:
>>> Also I have found the following article claiming that using gethrtime
>>> gives boost to MySQL performance even on Solaris 10:
>> I find this article highly suspicious since this hack exist at least
>> since July of 2007. Also, obviously, the explanation there is simply
>> wrong as we _can't_ use gethrtime for timing.
> Well, it is not very clear when this article was written.
> But it seems to be focused on MySQL 5.0 which AFAICS doesn't
> include this particular hack. This can explain its results.
> I agree that explanation is somewhat confusing. But in the end
> I think the suggestion in article boils down to using time()
> implementation which is based on gethrtime() similarly to
> hack in out code. This is achieved by linking MySQL with
> -lfasttime library described at
Similar in the sense that it has the same bug and is not thread safe --
the MySQL one is wrapper inside a mutex.
How about we ask the benchmark team to actually measure this patch?
>>> And finally please note that for 5.1 we still support Solaris 8 and 9:
>> What is your point?
> My point was that if, for example, time() became fast only starting from
> Solaris 10, we could not simply remove this hack from 5.1, as it would make
> MySQL 5.1 slower on one of its supported platforms.
Yes, but we still need to fix the bug, don't we? The hack is wrong.
Also, in the worst case, we could simply use gettimeofday.