List:General Discussion« Previous MessageNext Message »
From:Michael Widenius Date:January 6 2000 7:05pm
Subject:RE: CONCURRENT_INSERT?
View as plain text  
>>>>> "Steven" == Steven Roussey <sroussey@stripped> writes:

Steven> Hi!
Steven> We are thinking of moving to 2.23.8 ahead of schedule, so I have even more
Steven> questions. :)

Steven> 1. Does the concurrent insert/select also work with replace/select?

Sorry, no.  Changing an old row would introduce the problem that other
clients may get changed rows on reads (dirty reads), which we want to
avoid at this point.
Actually I hadn't thought about this when I fixed concurrent inserts.
If you are using REPLACE with MySQL 3.23, you have better apply the
following patch!

*** /my/monty/master/mysql-3.23.8-alpha/sql/sql_insert.cc	Tue Dec 28 05:41:30 1999
--- ./sql_insert.cc	Thu Jan  6 20:58:27 2000
***************
*** 98,104 ****
    DBUG_ENTER("mysql_insert");
  
    if (lock_type == TL_WRITE_DELAYED &&
!       (specialflag & (SPECIAL_NO_NEW_FUNC | SPECIAL_SAFE_MODE)))
      lock_type=TL_WRITE;
  
    if (lock_type == TL_WRITE_DELAYED)
--- 98,105 ----
    DBUG_ENTER("mysql_insert");
  
    if (lock_type == TL_WRITE_DELAYED &&
!       (specialflag & (SPECIAL_NO_NEW_FUNC | SPECIAL_SAFE_MODE)) ||
!       lock_type == TL_WRITE_CONCURRENT_INSERT && duplic == DUP_REPLACE)
      lock_type=TL_WRITE;
  
    if (lock_type == TL_WRITE_DELAYED)


Steven> 2. Is it better to mark records as deleted from an application point of view
Steven> (add a status column) rather than actually deleting them, so that their are
Steven> no empty slots?

If you really need the extra speed of concurrent inserts; Yes!

Steven> I think we will still need to break our table into 50 subtables soon.
Steven> Breaking them into 10 has worked so far, but increased traffic has made that
Steven> solution stop working. MySQL jams, but once a table gets locked up too
Steven> often, all the threads start filling up and it never can catch back up. But
Steven> I think the update to 23.8 and the breaking the tables will let us survive
Steven> the next 2-3 months. :)

By then we should have the option of using the new transactions safe
tables, which in effect gives you page locks.

Do you use fixed record-size or variable record-size tables?
For fixed size tables it would be quite easy to add insert even on
deleted slots which would of course give you dirty reads, but you can
maybe live with this?  In this case we probably need something like
INSERT DIRTY for this kind of inserts.

Steven> Monty and everyone else at TcX - thanks for all your work!

Thanks.

Regards,
Monty
Thread
CONCURRENT_INSERT?Dylan Neild13 Dec
  • Re: CONCURRENT_INSERT?sinisa13 Dec
  • Re: CONCURRENT_INSERT?Tonu Samuel14 Dec
  • CONCURRENT_INSERT?Michael Widenius5 Jan
    • Re: CONCURRENT_INSERT?Tim Bunce5 Jan
      • Re: CONCURRENT_INSERT?Michael Widenius5 Jan
        • Re: CONCURRENT_INSERT?Tim Bunce5 Jan
        • RE: CONCURRENT_INSERT?Steven Roussey6 Jan
          • RE: CONCURRENT_INSERT?sinisa6 Jan
          • RE: CONCURRENT_INSERT?Michael Widenius6 Jan
            • Re: CONCURRENT_INSERT?elble6 Jan
              • Re: CONCURRENT_INSERT?Michael Widenius7 Jan
RE: CONCURRENT_INSERT?Andy6 Jan