headers
Kathryn Steinbrink | 1 Jul 2008 21:53
Picon
Favicon

Supporting UCA collations


Hello,
I am developing a new storage engine.  Can you please give me your thoughts
on how important it is for my storage engine to support the following UCA
collations?  Are they popularly used by MySQL users and applications?   Do
you believe it will be acceptable to the MySQL community if the storage
engine does not support these collations in its initial stages and perhaps
for a few years?  Are there other MySQL storage engines that do not support
these collations?

ucs2_czech_ci                utf8_czech_ci
ucs2_danish_ci               utf8_danish_ci
ucs2_esperanto_ci          utf8_esperanto_ci
ucs2_estonian_ci            utf8_estonian_ci
ucs2_hungarian_ci          utf8_hungarian_ci
ucs2_icelandic_ci           utf8_icelandic_ci
ucs2_latvian_ci               utf8_latvian_ci
ucs2_lituanian_ci            utf8_lithuanian_ci
ucs2_persian_ci             utf8_persian_ci
ucs2_polish_ci               utf8_polish_ci
ucs2_roman_ci               utf8_roman_ci
ucs2_romanian_ci          utf8_romanian_ci
ucs2_slovak_ci               utf8_slovak_ci
ucs2_slovenian_ci          utf8_slovenian_ci
ucs2_spanish_ci            utf8_spanish_ci
ucs2_spanish2_ci           utf8_spanish2_ci
ucs2_turkish_ci              utf8_turkish_ci
ucs2_unicode_ci             utf8_unicode_ci

Thank you!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Scara Maccai | 2 Jul 2008 16:58
Picon
Favicon

Re: position and rnd_pos

Sergei Golubchik wrote:
> Here's the one with filesort (I used MyISAM below):
>
> create table t1 (a varchar(200));
> insert t1 values (rand());
> insert t1 select rand() from t1;
> insert t1 select rand() from t1;
> insert t1 select rand() from t1;
> insert t1 select rand() from t1;
> insert t1 select rand() from t1;
> select * from t1 order by a limit 5;
>
> The last one has tripped over my breakpoint in ha_myisam::position().
>
>   

Ok, thank you
> MySQL doesn't ask you to allocate anything, so MySQL won't free it
> either. You're expected to put the "position" in this->ref. MySQL will
> copy it out from there. Later it'll use this copy as an argument for
> rnd_pos(). What is it that you need to be released ?
>   
I didn't see

if (!(ref= (byte*) alloc_root(&table->mem_root, ALIGN_SIZE(ref_length)*2)))

in handler.cc

So I thought that my_store_ptr was allocating memory (since ref is a 
byte*), hence I thought that I needed to free it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
MARK CALLAGHAN | 3 Jul 2008 01:17
Picon

Coverity Scan and MySQL

Why doesn't MySQL participate in the Coverity Scan project? This would
provide static-analysis for free. PostgreSQL and SQLite participate.
http://scan.coverity.com/faq.html

-- 
Mark Callaghan
mdcallag <at> gmail.com

--

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals?unsub=gcdmd-internals <at> m.gmane.org
Permalink | Reply | 2 comments |
headers
Chad MILLER | 3 Jul 2008 16:20
Picon
Favicon

Re: Coverity Scan and MySQL


On 2 Jul 2008, at 19:17, MARK CALLAGHAN wrote:

> Why doesn't MySQL participate in the Coverity Scan project? This would
> provide static-analysis for free. PostgreSQL and SQLite participate.
> http://scan.coverity.com/faq.html

This looks worthwhile.  I'll add our server source.  Thanks, Mark.  -  
chad

-- 
Chad Miller, Sun Microsystems DB Group   chad <at> mysql.com   Orlando,  
Florida, USA

--

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals?unsub=gcdmd-internals <at> m.gmane.org
Permalink | Reply | 1 comment |
headers
Sergei Golubchik | 3 Jul 2008 17:53
Picon
Favicon

Re: Coverity Scan and MySQL

Hi!

On Jul 03, Chad MILLER wrote:
>
> On 2 Jul 2008, at 19:17, MARK CALLAGHAN wrote:
>
>> Why doesn't MySQL participate in the Coverity Scan project? This would
>> provide static-analysis for free. PostgreSQL and SQLite participate.
>> http://scan.coverity.com/faq.html
>
> This looks worthwhile.  I'll add our server source.  Thanks, Mark.  - chad

Just to remind that MySQL sources were analyzed by Coverity few times
(first time, if I'm not mistaken, it was 4.0.16, then some 5.x).

Which, of course, doesn't mean we shouldn't do it again :)

Regards / Mit vielen Grüssen,
Sergei

-- 
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik <serg <at> mysql.com>
 / /|_/ / // /\ \/ /_/ / /__  Principal Software Engineer/Server Architect
/_/  /_/\_, /___/\___\_\___/  Sun Microsystems GmbH, HRB München 161028
       <___/                  Sonnenallee 1, 85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Häring

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
MARK CALLAGHAN | 3 Jul 2008 19:20
Picon

mutex contention for the query cache

The query cache has a mutex that is locked while it is searched. This
is not a spin lock, so many threads will go to sleep when there is
contention. And it is made worse because work is done to create the
search key in Query_cache::send_result_to_client() (work == memory
allocation and other byte copying) after the mutex is locked.

Are there plans to fix this?
I don't have benchmark results (yet), but I am willing to bet that
this is a problem.

-- 
Mark Callaghan
mdcallag <at> gmail.com

--

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals?unsub=gcdmd-internals <at> m.gmane.org
Permalink | Reply | 32 comments |
headers
MARK CALLAGHAN | 3 Jul 2008 19:28
Picon

Re: mutex contention for the query cache

Things have changed from 5.0.37 to 5.0.62. Someone added spin lock
behavior for non-windows platforms. Work is still done to initialize
the search key after the lock is obtained. But that work does not
include memory allocation.

Any chance the inlined spin lock can get put into a class so we have
some chance of reuse?

From Query_cache::send_result_to_client():

#ifdef __WIN__
  STRUCT_LOCK(&structure_guard_mutex);
#else
  stop_time= my_clock()+(ulong)lock_time_treshold*CLOCKS_PER_SEC;
  while ((lock_status= pthread_mutex_trylock(&structure_guard_mutex)) == EBUSY
         && spin_count < spin_treshold
         && new_time < stop_time)
  {
    spin_count++;
    if (spin_count%5)
      new_time= my_clock();
    my_sleep(0);
  }

  if (lock_status != 0)
  {
    /*
      Query cache is too busy doing something else.
      Fall back on ordinary statement execution. We also mark this
      query as unsafe to cache because otherwise this thread will
(Continue reading)

Permalink | Reply | 25 comments |
headers
MARK CALLAGHAN | 3 Jul 2008 19:45
Picon

Re: mutex contention for the query cache

On Thu, Jul 3, 2008 at 10:28 AM, MARK CALLAGHAN <mdcallag <at> gmail.com> wrote:
> Things have changed from 5.0.37 to 5.0.62. Someone added spin lock
> behavior for non-windows platforms. Work is still done to initialize
> the search key after the lock is obtained. But that work does not
> include memory allocation.
>
> Any chance the inlined spin lock can get put into a class so we have
> some chance of reuse?
>

And astute readers will notice this isn't a spin lock as it sleeps
immediately after each failure to get the lock.

> From Query_cache::send_result_to_client():
>
> #ifdef __WIN__
>  STRUCT_LOCK(&structure_guard_mutex);
> #else
>  stop_time= my_clock()+(ulong)lock_time_treshold*CLOCKS_PER_SEC;
>  while ((lock_status= pthread_mutex_trylock(&structure_guard_mutex)) == EBUSY
>         && spin_count < spin_treshold
>         && new_time < stop_time)
>  {
>    spin_count++;
>    if (spin_count%5)
>      new_time= my_clock();
>    my_sleep(0);
>  }
>
>  if (lock_status != 0)
(Continue reading)

Permalink | Reply | 24 comments |
headers
Rick James | 3 Jul 2008 20:17
Picon
Favicon

RE: mutex contention for the query cache

Any clue of how often a thread cannot get to the query cache on first
try?

 
Rick James
MySQL Geeks - Consulting & Review

> -----Original Message-----
> From: MARK CALLAGHAN [mailto:mdcallag <at> gmail.com] 
> Sent: Thursday, July 03, 2008 10:45 AM
> To: internals <at> lists.mysql.com
> Subject: Re: mutex contention for the query cache
> 
> On Thu, Jul 3, 2008 at 10:28 AM, MARK CALLAGHAN 
> <mdcallag <at> gmail.com> wrote:
> > Things have changed from 5.0.37 to 5.0.62. Someone added spin lock
> > behavior for non-windows platforms. Work is still done to initialize
> > the search key after the lock is obtained. But that work does not
> > include memory allocation.
> >
> > Any chance the inlined spin lock can get put into a class so we have
> > some chance of reuse?
> >
> 
> And astute readers will notice this isn't a spin lock as it sleeps
> immediately after each failure to get the lock.
> 
> > From Query_cache::send_result_to_client():
> >
> > #ifdef __WIN__
(Continue reading)

Permalink | Reply | 23 comments |
headers
Sergei Golubchik | 3 Jul 2008 20:28
Picon
Favicon

Re: Coverity Scan and MySQL

Hi!

On Jul 03, Michael Izioumtchenko wrote:
> Hi Sergey,
>
> what do you think about usefulness of Coverity analysis, from past
> experience?
> [not sure if my question merits a post to the internals list, if you
> think otherwise, please feel free to cc: your answer to the list]

Pretty good.
Very impressive, if compared with other tools.

> Sergei Golubchik wrote:
>> On Jul 03, Chad MILLER wrote:
>>> On 2 Jul 2008, at 19:17, MARK CALLAGHAN wrote:
>>>     
>>>> Why doesn't MySQL participate in the Coverity Scan project? This would
>>>> provide static-analysis for free. PostgreSQL and SQLite participate.
>>>> http://scan.coverity.com/faq.html
>>>>       
>> Just to remind that MySQL sources were analyzed by Coverity few times
>> (first time, if I'm not mistaken, it was 4.0.16, then some 5.x).
>>
>> Which, of course, doesn't mean we shouldn't do it again :)
>>
Regards / Mit vielen Grüssen,
Sergei

--

--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane